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SHIPMENT TRANSACTION SYSTEM AND AN ARRANGEMENT THEREOF 

5 

Related Patent Documents 

The instant application is a continuation-in-part of U.S. Patent Application 
Serial No. 60/124,124 filed on March 12, 1999 entitled "Shipment Transaction System 
And An Arrangement Thereof, which is a continuation-in-part of U. S. Patent 

1 0 Application Serial No. 08/748,243, filed November 4, 1996, with the same title 
(USBA.02PA), both of which are incorporated herein by reference. The instant 
application is also related to U.S. Patent Application Serial No. 09/259,657, filed 
February 26, 1999, entitled "Shipment Transaction System And Method" 
(USBA.02C1), and related to U. S. Patent Application Serial No. 09/310,71 1, filed May 

15 12, 1999, with the same title, both of which are continuations of U.S. Patent Application 
Serial No. 08/748,243 and are incorporated herein by reference. 

Field of the Invention 

2 0 The present invention relates to a computer processing system for shipment 

transactions involving a shipper and a carrier or a vendor and service providers where 
the transaction involves services. 

2 5 Background of the Invention 

Processing shipment transactions between a shipper and a carrier has been a 
manually intensive effort and has experienced little change. Generally, the shipment 
transaction process involves a goods transport path and a payment process path. The 
goods transport path typically starts when a carrier picks up the goods at the shipper's 

3 0 warehouse dock. The carrier receives a copy of a transaction document, sometimes 
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referred to as a bill of lading (BOL), from the shipper. This type of transaction 
document includes information associated with the shipment transaction that is used by 
the shipper and carrier to track the shipment of goods. The carrier transports the goods 
to the receiver where the receiver signs a copy of the BOL to verify receipt of the goods. 
5 After the carrier has delivered the goods to the receiver, the carrier also submits the 
receiver's signed copy of the BOL to the carrier's headquarters. 

At this point, records are generated that contain information about requested 
pick-up and delivery times, origin and destination, and type of load. The first problem 
in the process can occur when the carrier arrives to pick up the load. If the shipment is 

1 0 not ready or there are delays at the loading dock, accessorial charges may be imposed 
by the carrier. Because they are not part of the original BOL, the shipper may dispute 
these charges later, and this can cause payment delays down the line. Back at the 
loading dock, a second problem is created when manual changes are made on the BOL. 
Unfortunately, these changes rarely get recorded in the shipper's permanent electronic 

1 5 records causing a difference between the shipper's and the carrier's paperwork for the 
same load. 

Now on the road, the driver needs to send the paperwork back to headquarters. 
Because the primary job of the driver is to get the shipment to its destination in a timely 
manner, paperwork can sometimes be delayed, and it may be days before the carrier 
2 0 headquarters receives a copy of the BOL. 

The driver reaches the destination and delivers the shipment. At the point of 
delivery, the driver is supposed to provide notification of delivery. Again, this may or 
may not happen. When it does not, vital information is delayed or missing in the supply 
chain. 

2 5 When the original and delivery copies of the BOL finally reach the clerk at the 

carrier's offices, the clerk sends out an invoice for the original shipment. A clerk at the 
shipper's office receives the invoice, often amid a pile of invoices for many carriers, and 
attempts to match the invoice with a copy of the original BOL. If a billing error is 
discovered, the clerk might send a check for a partial payment or simply hold the entire 

3 0 payment until the corrected invoice is provided. The carrier clerk receives this check 
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and must then track down the original BOL and delivery copy to know why the check is 
for less than the total amount due. It is only after communicating wit the shipper 
directly that the carrier finds out a mistake was made in the original paperwork. The 
carrier sends the shipper an amendment to the original invoice, and the shipping clerk 
5 must then organize and file all the paperwork together. 

The payment process path starts when the carrier picks up the goods from the 
shipper. The carrier sends a copy of the BOL to the carrier's headquarters for 
processing. The carrier headquarters rates the BOL. Rating involves determining the 
shipment cost that takes into the account various shipment parameters such as the size, 

1 0 weight, type of material, and destination of the shipment. The carrier creates an invoice, 
sets up an accounts receivable, and sends the invoice to the shipper's accounts payable 
department. The shipper, either internally or via a third party, audits the invoice to 
ensure the final cost is proper. 

One of the more burdensome aspects of the traditional process involves reaching 

15 agreement as to the final cost. If there is a dispute as to final cost, the shipper and 

carrier begin a burdensome and sometimes lengthy negotiation process in an attempt to 
settle the dispute. If the dispute is resolved, the shipper sets up an accounts payable for 
the transaction. The shipper will then send payment to the carrier and clear the accounts 
payable. The traditional process for paying the carrier and clearing the accounts payable 

2 0 involves several manually intensive steps. Upon receipt of payment, the carrier clears 
the accounts receivable. The traditional process for clearing an accounts receivable 
includes the carrier manually inputting final payment information into the accounts 
receivable system. 

The traditional approach can lead to many disadvantages for a transaction 

2 5 between one shipper and one carrier. Typically, however, there are multiple carriers and 

shippers involved in multiple transactions, which makes the situation more complex, 
and that much more slow and inefficient. The process is manually intensive in that it 
relies on the hard copy of the BOL for proof of delivery and payment, resulting in a 
series of repetitive and time-consuming steps. Also, each BOL is often rated multiple 

3 0 times by multiple parties creating excessive redundancy. 
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Traditional shipment transaction systems are also highly susceptible to billing 
errors and fraud. For example, there is no connection between the delivery of goods and 
when the shipper is billed for delivery. This may result in double billing, no billing at 
all, or over-billing the shipper for freight delivery charges. Also, auditing error may 
5 occur which results in incorrect billing or payment. In addition, the carrier waits a 
disproportionately long time for payment while the invoice is being audited and/or 
disputed. For example, traditionally, a delivery takes about five days whereas payment 
takes about thirty days. This unnecessary delay adversely affects the carrier's working 
capital resources. 

1 0 Additional costs arise as a result of the existing inefficiencies. Many of the costs 

are individually small, but very large in the aggregate. For example, the carrier incurs 
administrative costs including: the cost to create and deliver the initial invoice, costs of 
resolving billing disputes, costs of providing a signed copy of the BOL to the shipper, 
and costs of posting accounts receivable. The shipper incurs similar administrative 

15 costs. 

Another disadvantage of traditional shipment transaction systems is that they 
have a tendency to strain relationships. Because carriers and shippers do not always 
have an effective way to communicate about the shipment, business partnerships can be 
strained when there are disputes. Continuous inaccuracies in either the shipment or 
2 0 invoice process cerate unnecessary tension along the entire supply chain for both 
shippers and carriers. 

An additional disadvantage involves the inability to obtain immediate 
information regarding a shipment. Since the process is largely conducted manually, it is 
very difficult to track a shipment. To learn of the status of shipment or payment, there 

2 5 are various manual steps involved. For example, if the shipper wants to know if the 

carrier delivered the goods and if the payment has been made, the shipper must call the 
carrier and the appropriate financial institution. 

There have been numerous attempts to improve the existing shipment and 
payment process. Some improvements have been made to each separate step of 

3 0 completing a shipment transaction, but the entire method remains relatively unchanged. 
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For example, freight agents are used by shippers to schedule shipments and to process 
the invoice from the carrier. Also, third party service providers have taken over the role 
of managing the shipper's accounts payable department. 

Another attempt to improve this burdensome transaction process involves the 
5 use of the Internet. Carriers have offered Internet access to their shipment information. 
Shippers access the carrier's Internet address and find out the immediate status of the 
shipment. A disadvantage of this system arises when, as in many applications, the 
shipper is using multiple carriers. In this typical situation, the shipper separately 
accesses the address of each carrier in order to find out the status of each shipment. 
1 0 This is unduly time-consuming. 

Another disadvantage of traditional systems is that the shipper's reference 
number and the carrier's reference number are not compatible. The carrier maintains 
the shipment data, so the shipper accesses the data using the carrier's reference number 
rather than the shipper's reference number. The shipper and carrier track each shipment 
1 5 using multiple reference numbers . 

These various attempts to improve the overall process have fallen short of 
providing a convenient and cost effective system to process a shipment transaction. 

Summary of the Invention 

2 0 The present invention is directed to a shipment transaction system for processing 

transaction information related to goods shipped from a shipper by a carrier. According 
to one example implementation of the present invention, the system includes a 
processor arrangement that maintains shipper credit data for shippers and to process the 
transaction information in response to control data communicatively coupled between 

2 5 the processor arrangement and users of at least one type. The processor arrangement is 

linked with various users via a communications channel, and is programmed to receive 
control data from the users, to verify that the received control data is from an authorized 
source, and to evaluate the shipper credit data and the control data. In response, the 
processor arrangement determines whether to generate data that authorizes payment to 

3 0 the appropriate carrier(s). 
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According to another example implementation of the present invention, a 
shipment transaction system includes a processor arrangement programmed and 
configured to maintain shipper credit data of said one of a plurality of shippers, to 
process the transaction information in response to control data communicatively 
5 coupled between the processor arrangement and users of at least one type, and to 
automatically audit shipment transactions between shippers and carriers. The system 
further includes at least one communication channel communicatively linking the 
processor arrangement with the users of said at least one type, with the processor 
arrangement being further programmed to receive control data from the users, to verify 

1 0 that the received control data is from an authorized source, and to evaluate the shipper 
credit data and the control data and, in response, to determine whether to generate 
authorization data that authorizes payment to one of a plurality of carriers. 

More specific implementations of one or both of the above systems involving 
the following. The processor arrangement permits authorized ones of the shippers and 

1 5 authorized ones of the carriers to review audit discrepancies using a communication 
channel communicatively coupled with the processor arrangement. The processor 
arrangement permit authorized ones of the shippers to approve payment to selected ones 
of the carriers without adversely impacting credit data of the authorized shippers, and 
permits authorized ones of the carriers to delay shipment for selected ones of the 

2 0 shippers without adversely impacting credit data of the authorized carriers. 

In yet another embodiment, a shipment transaction system includes a processor 
arrangement programmed and configured to maintain shipper credit data of a shipper, to 
process the transaction information in response to control data communicatively 
coupled between the processor arrangement and users of at least one type, and to 

2 5 maintain a database of shippers and carriers, the database having a main parameter set 

for validating ones of the shippers and carriers that are qualified as users thereof and 
having respective data sets for the validated shippers and carriers indicating varying 
communication access levels for communicators of each respective validated shipper 
and carrier. At least one communication channel communicatively links the processor 

3 0 arrangement with the users of said at least one type, and the processor arrangement is 
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audits shipment transactions and reports thereon to at least one of the validated shippers 
and carriers according to one of the varying communication access levels for 
communicators of the validated shipper and/or carrier. 

Another more specific embodiment involve the above shipment transaction 
5 system with the processor arrangement further programmed and configured to audit 
shipment transactions and report thereon to at least one of the validated shippers and 
carriers according to different communication access levels, each being defined based 
on data provided by a respective one of the validated shippers and carriers. Further, the 
processor arrangement can be configured and arranged to permit and block access to 

1 0 shipment transaction information according to information stored in the database, and 
the database can include information defining payment authorization levels for 
communicators, wherein the processor arrangement permits approval for payment to 
carriers for shipment transactions according to the information defining payment 
authorization levels. As enhancements to this implementation, the information defining 

15 payment authorization levels for communicators in the database is defined by a 

specified type of user, and the information defining payment authorization levels for 
communicators is downloaded into the database from the user at a remote site. 

According to one application, the present invention is directed to a transaction 
validation system for auditing transaction information related to services provided by 

2 0 one of a plurality of vendors and processed by one of a plurality of service providers. 
The system comprises a central processor arrangement programmed and configured to 
maintain data relating to an authorized profile list criterion that includes information 
about authorized users empowered to authorize payment by the vendor, and 
programmed and configured to process the transaction information by determining 

2 5 whether the transaction information satisfies the authorized profile list criterion, and 

using the authorized profile list criterion to generate information for auditing a 
transaction between one of a plurality of vendors and one of a plurality of service 
providers. 

According to another application, the present invention is directed to a transaction 

3 0 validation system for auditing transaction information related to services provided by a 
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vendor and a plurality of subvendors and processed by one of a plurality of subvendor 
controlled service providers. The system comprises a central processor arrangement, 
coupled to vendor and subvendor, programmed and configured to maintain data relating 
to an authorized profile list criterion that includes information about authorized users 

5 empowered to authorize payment by the vendor, and programmed and configured to 
process the transaction information by determining whether the transaction information 
satisfies the authorized profile list criterion, and using the authorized profile list 
criterion to generate information for auditing a transaction between the vendor and both 
of the plurality of subvendors and plurality of subvendor controlled service providers. 

1 0 According to another application, the present invention is directed to a 

transaction validation system for auditing transaction information related to services 
provided by a vendor, the transaction information being generated by one of a plurality 
of service providers prior to processing by the vendor. The system comprises a central 
processor arrangement programmed and configured to maintain data relating to an 

1 5 authorized profile list criterion that includes information about authorized users 

empowered to authorize payment by the vendor to service provider, and programmed 
and configured to process the transaction information by determining whether the 
transaction information satisfies the authorized profile list criterion, and using the 
authorized profile list criterion to generate information for auditing a transaction 

2 0 between the vendor and one of a plurality of service providers. 

Other aspects of the present invention are directed to methods for implementing 
the computer operations at a central control center, and to arrangements and methods for 
configuring and operating the coordination of the above-characterized shipment 
transaction system at the shipper's station and with respect to the carrier. 

2 5 The above summary of the present invention is not intended to describe each 

illustrated embodiment, or every implementation, of the present invention. This is the 
purpose of the figures and of the detailed description that follows. 

Brief Description of the Drawings 
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Other aspects and advantages of the invention will become apparent upon 
reading the following detailed description and upon reference to the drawings in which: 

FIG. 1 is a block diagram illustrating a specific embodiment that incorporates 
principles of the present invention; 
5 FIG. 2 is a block diagram illustrating an example flowchart for programming the 

shipper processor 24 of FIG. 1 according to the present invention; 

FIG. 2a is a block diagram illustrating an example flowchart for programming 
the BOL rating engine 30 of FIG. 1 according to the present invention; 

FIG. 3 is a block diagram illustrating an example flowchart for programming the 
1 0 data processing device 34 of FIG. 1 according to the present invention; 

FIG. 4 is a block diagram illustrating an example flowchart for programming the 
central processor 40 of FIG. 1 manipulating the transaction information according to the 
present invention; 

FIG. 5 is a block diagram illustrating an example flowchart for programming the 
1 5 issuing processor 45 of FIG. 1 authorizing a transaction according to the present 
invention; 

FIG. 6 is a block diagram illustrating an example flowchart for programming the 
VRU unit 48 according to the present invention; 

FIG. 7 is a block diagram illustrating an example flowchart for programming the 
2 0 central processor 40 of FIG. 1 generating a deposit file according to the present 
invention; 

FIG. 8 is a block diagram illustrating an example flowchart for programming the 
paying processor 54 of FIG. 1 according to the present invention; 

FIG. 9 is a block diagram illustrating an example flowchart for programming the 
2 5 issuing processor 45 of FIG. 1 crediting a transaction according to the present invention; 

FIGs. 1 OA- 10C are flow diagrams depicting an example operation of 
implementing ship transaction using the data processing flow addressed herein, 
according another aspect of the present invention; 
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FIG. 1 1 illustrates a communication path from an architectural perspective in 
which an array of computers and data routers are used in an example implementation of 
a system and method, according another aspect of the present invention; 

FIG. 12 is a block diagram illustrating another embodiment of the invention 
directed to services that incorporates principles of the present invention; 

FIG. 13 is a block diagram illustrating another embodiment directed to services 
and having a modified relationship between vendor and service provider; and; 

FIG. 14 is a block diagram illustrating another embodiment having a modified 
relationship between a vendor, subvendors and service providers. 

While the invention is susceptible to various modifications and alternative 
forms, specific embodiments thereof have been shown by way of example in the 
drawings and will herein be described in detail. It should be understood, however, that 
it is not intended to limit the invention to the particular forms disclosed. On the 
contrary, the intention is to cover all modifications, equivalents, and alternatives falling 
within the spirit and scope of the invention as defined by the appended claims. 

Detailed Description 

The present invention is generally applicable to a computer processing system 
for a shipment transaction involving a shipper and a carrier. The present invention has 
been found to be particularly advantageous for a system which efficiently automates the 
payment of a shipment transaction and efficiently provides access to shipment 
information. 

The present invention is generally directed to a system that automates the 
shipment transaction process to thereby provide a convenient transaction protocol 
between the delivery, billing, and payment aspects of the transaction. 

In one embodiment of the present invention, a computer arrangement includes a 
main CPU communicatively coupled via the Internet to provide around the clock access 
of shipment transaction data to authorized shippers, carriers, operators of the main CPU 
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and, in more specific implementations, a separate financial institution and/or an auditor 
that is independent of the shippers, carriers, and CPU operators (and if applicable the 
separate financial institution). As is conventional with Internet communications, 
5 electronic notes can be included for supplemental communication with anyone in the 
shipment transaction chain. The main CPU maintains a database of all information 
relating to the shipments of the carriers and shippers, and the main CPU is used to 
analyze the shipments for auditing purposes, effect payments, to facilitate changes to the 
rating systems, and to facilitate resolution of audit discrepancies. 
1 0 When a problem arises with a shipment, for example, the shipper (or the carrier 

if preferred) can change the rating via the Internet, Moreover, the shipper can instruct 
the main CPU to delay payment. Similarly, the carrier can inform the main CPU that a 
delivery of a shipment is being delayed due to its problems in receiving payments from 
the shipper. 

15 By permitting the shipper access to analysis of the information database, the 

shipper can inquire of the main CPU data useful in assisting the shipper address issues, 
such as: which carrier has the best on-time delivery record, and which carrier has the 
most cost-effective service between two locations. Carriers can also use such data to 
addresses issues such as to identify the shipper that generates the most business in a 

2 0 target region. Further, all users of the system have the potential to access an abundance 
of historical data including, for example, approval history, and delivery and payment 
information. 

As shown in FIG. 1, a shipper processor 24 initiates the shipment transaction by 
acting in conjunction with a BOL rating engine 30 to generate a rated BOL. The 

2 5 shipper processor sends the rated BOL to a data processing device 34 of a shipper 

access terminal 32. The data processing device 34 generates transaction information 
and sends the transaction information to a central processor 40. The central processor 
40 identifies and centrally tracks the transaction information. A carrier processing 
device 46 receives proof of delivery information and sends this information to the 

3 0 central processor 40. The central processor 40 processes and stores all pertinent 
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shipment information in a data storage unit 42 and allows immediate access to this 
information by the shipper 20, the carrier 22, and other authorized users. This reduces 
the administrative costs of the shipper 20 and the carrier 22. The central processor 40 
interfaces with an improved payment system including an issuing institution 44 and a 
paying institution 52. An issuing processor 45 of the issuing institution 44, maintains a 
credit account for the shipper 20 and debits the shipper's account for the cost of the 
shipment. A paying processor 54 of the paying institution 52 tenders payment to the 
carrier 24. 

FIG. 2 is a block diagram illustrating an example flowchart for programming the 
shipper processor 24 of FIG. 1 according to the present invention. According to this 
example flowchart, the shipper processor 24 receives 200 an input of relevant purchase 
order information for storage and processing using an adequate input device 202. Using 
a conventional desktop PC for example, a keyboard and mouse are adequate input 
devices. Using a more complex computer arrangement, a digital retrieving device, such 
as an information scanner, is used to offset some of the labor associated with this 
inputting effort. 

The shipper processor 24 processes 204 the purchase order information 
including referencing inventory control and customer information systems to generate 
206 shipment parameters. In a particular application, the shipment parameters include 
the identity of the carrier, identity of the receiver, the number of units, the weight of the 
shipment, the destination of the shipment, the date of shipment, and the estimated date 
of delivery. The shipper processor 24 is located at the shipper's premises so that the 
shipper processor 24 receives accurate information resulting in further reliability and 
efficiency of the system. 

The shipper processor 24 electronically sends 208 the shipment parameters to 
the BOL rating engine 30. The transmission is accomplished conventionally. The BOL 
rating engine 30 of the illustrated embodiment of FIG. 1, is designed to suit the needs of 
the particular shipper, the type of goods shipped, and to provide an interface to the 
shipper processor 24. Conventionally, BOL rating engines, which are in use today, are 
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implemented using a computer processing device such as a stand-alone personal 
computer, a personal computer connected to a network, or a conventional mainframe. 

FIG. 2a is a block diagram illustrating an example flowchart for programming 
the BOL Rating Engine 30 of FIG. 1 according to the present invention. The BOL 
5 rating engine receives 216 the shipment parameters and processes 218 the shipment 
parameters. The BOL Rating Engine 30 generates 220 a rated BOL. The BOL rating 
engine 30 is programmed to an agreed upon rate structure by the shipper 20 and carrier 
22. As a result, the BOL rating engine 30 produces consistently rated BOL's. This has 
the further advantage that the shipper 20 and the carrier 22 do not have to audit the 
1 0 engine often. Existing systems require frequent auditing of the results of the BOL 

rating engine. With no post audit adjustments, the payment to the carrier 22 is definite. 

The BOL rating engine 30 sends 222 the rated BOL to the shipper processor 24. 
In a particular application, the BOL rating engine 30 is included in the shipper processor 
24. The shipper processor 24 performs the rating function of the BOL rating engine 30 
15 so that there is no need to send the shipment parameters to an external BOL rating 

engine. The shipment parameters are processed and a rated BOL is generated solely by 
the shipper processor 24. 

Another advantage associated with the process in which a rated BOL is 
produced is that only one BOL rating engine 30 is needed for the entire shipment 
2 0 transaction system. This saves duplicate efforts by the carrier 22 and ensures exact 

payment. A significant benefit of this illustrated embodiment of FIG, 1 is that the cost 
depicted on the BOL is the final cost of shipment. Therefore, the shipper 20 and carrier 
22 will immediately know the final cost of shipment before the goods are delivered. 
The BOL rating engine 30 removes ambiguity from the shipment transaction payment 
2 5 process which significantly offsets time-consuming payment disputes. 

The shipper processor 24 receives 212 the rated BOL and sends 214 the rated 
BOL to a shipper access terminal 32 located at the shipper's premises. In an alternative 
embodiment, the BOL rating engine 30 is located off the shipper's premises so that the 
shipper processor 24 can access the BOL rating engine 30 on an as-needed basis. One 
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advantage is that one standardized BOL rating engine could be electronically linked to 
multiple shipper processors thereby reducing the cost to each individual shipper. 

FIG. 3 is a block diagram illustrating an example flowchart for programming the 
data processing device 34 of FIG. 1 according to the present invention. The shipper 
5 access terminal 32 contains a data processing device 34 that receives 300 the rated 
BOL. The data processing device 34 validates 312 the rated BOL to ensure that the 
rated BOL contains data that is complete, error-free, and properly formatted. The data 
processing device 34 processes 312 the rated BOL and generates 316 a list of 
transaction information. The transaction information includes the information as seen in 
1 0 table 1 below. The columns in Table 1 represent the following: Data Element is the 
data that will reside in that particular element location, Length is the length of the data 
element; type is the type of data element which is either numeric or alpha-numeric, and 
Description simply describes the function of the data element if necessary. 

1 5 Table 1 - Transaction Information 



Data Element 


Length 


Type 


DESCRIPTION 


Shipper ID 


10 


N 


Record ID 


Dock ID 


3 


N 


Record ID 


Bill of Lading # 


15 


AN 


Record ID 


Ship Date 


8 


N 


Record ID, reporting 


SCAC 


4 


A 


Standard Carrier Alpha Code, a national 
standardized carrier identification code. 


Carrier Vendor 
Number 


10 


N 


Alternate index, allows Shipper 20 to 
specify its vendor number for a given 
carrier 22 


Customer Number 


10 


N 


Alternate index, allows shipper 20 to 
specify it's customer number for a 
given receiver 


Customer PO # 


15 


AN 


Alternate index, reporting 


Shipper Order # 


15 


AN 


Alternate index 


Vendor Order 
Number 


15 


AN 


Reporting, alternate locator, carrier 22 
PO associated with shipment 


Shipper Name 


35 


AN 




Shipper Contact 
Person 


20 


A 
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iJata Element 


Length 


lype 




Shipper Phone # 




A XT 




Origin Designator 


1U 


A XT 




City 


ZU 


A XT 




Mate 


z 


A 


_ 


ZIP Code 




XT 
IN 




Division Code 


z 


A XT 




Reference B/L#l 


15 


AN 


Consolidated Shipments 


Reference B/L #2 


15 


A XT 

AJN 


Consolidated Shipments 


Reference B/L #3 


15 


AN 


Consolidated Shipments 


Bill of Lading Type 


l 


A XT 

AN 


Reporting 


Shipment Mode 


3 


A "X T 

AN 


Less than Truck Loaa(LIL) ? Iruck 

t s\c*a /tt t?oi1 n? A r\ ATI? 
JLoaa ^11^), Kan (Ivajlj, aik 


Inbound, Outbound 

T71 „ ~ 

Flag 


1 


A XT 

AJN 




Prepaid, Collect Flag 


-i 
1 


A XT 

AJN 




COD Flag 


1 


XT 

JN 




COD Amount 


a o 

y.z 


XT 

JN 




Shipment Value 


a o 

9.2 


XT 

JN 




Driver Name 


20 


A XT 

AJN 




Trailer/Car # 


1 C 
I J 


A XT 

AJN 




Trailer/CarSeal# 




A XT 

AJN 




Import, Export Flag 


I 


A XT 

AJN 




# Stops 


2 


XT 

N 




Stop Off Charges 


7.2 


XT 




Rated Freight Charges 


a i 

y.2 


XT 

JN 




Cube Dimensions 


c 

J 


XT 

JN 




Shipment as weight 


/.2 


XT 

JN 





Accessorial Charges 


/.2 


XT 

JN 




lotal freight Cngs 


y.2 


XT 
JN 


— — — — — ~ 


Destination Name 


25 


AN 




Destination City 


20 


A XT 

AN 




Destination State 


2 


A 

A 




Destination Zip Code 


9 


XT 




Destination Area 
Code 


o 


XT 
IN 




Destination Prefix 


3 


N 




Destination Phone 


4 


N 




Mileage 


5 


N 





The data processing device 34 sends the transaction information to a central 
processor 40. In one embodiment, the data processing device 34 is implemented using a 
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conventional personal computer programmed to operate under the control of an 
operating system stored in the memory. These types of computer arrangements are not 
presently programmed to conventionally interface with a central processing center and a 
processing device located at a shipper's premises. One advantage of interfacing the 
5 central processor 40 with shipper access terminal 32 is that the shipper access terminal 
32 can control the quantity, quality, and timing of information that is transmitted 
between the shipper processor 24 and the central processor 40. The access terminal 32 
can also control the communication sessions between the shipper processor 24 and the 
central processor 40. The shipper access terminal 32 is designed so that the shipper 20 

1 0 may directly access the transaction information. The shipper 20 will not be allowed to 
make changes to the transaction information, but is able to add additional information. 
This ensures the integrity of the transaction information. An additional advantage of the 
access terminal 32 is that the data processing device 34 can receive real-time 
information from the shipper processor 24 regarding the shipment transaction. 

15 In an alternative embodiment, the shipper access terminal 32 is linked to a 

magnetic stripe card reader. The card reader accepts a card and transmits the data 
contained therein to the data processing device 34 of the shipper access terminal 32. 
The magnetic stripe card reader accepts an identification card from a user of the system. 
The identification card contains relevant user information. In an alternative application, 

2 0 the access terminal 32 is linked to a bar code reader that is designed to receive 

information from a bar code and input the bar code information into the data processing 
device 34. The bar code is printed on the BOL or on a carrier identification card. 

The data processing device 34 sends 318 the transaction information to the 
central processor 40. The design of the central processor 40 is dictated by the desired 

2 5 speed, the number of users, and the amount of data to be processed. 

FIG. 4 is a block diagram illustrating an example flowchart for programming the 
central processor 40 of FIG. 1 to manipulate the transaction information according to 
the present invention. The central processor 40 receives 402 the transaction information 
and performs 404 an integrity check on the incoming information to ensure that the 

3 0 information is correctly formatted and contains no errors. If the integrity check is 
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unsuccessful, the transaction information is stored in a suspense file in a data storage 
unit 42. Once the error is corrected, the corrected transaction may be sent into the 
normal process flow. If the integrity check is successful, the central processor 40 
retrieves 406 authorized user profile lists from the data storage unit 42. 
5 The data storage unit 42 is essentially a memory unit that stores information 

relevant to the shipping transaction. The design of the data storage unit 42 is dictated 
by the amount of data needed to be stored. 

The authorized user profile lists represent the users and combination of users 
that are authorized to use the system. Authorized user profile lists include a shipper 

1 0 profile list, a carrier profile list, a carrier/shipper profile list, and a shipper access 

terminal profile list. The profile lists provide the cross-reference between the payment 
ID (assigned by central processor 40), an account ID (assigned by an issuing processor 
45), and a merchant number (assigned by a paying processor 54). 

An authorized shipper profile list identifies information regarding the shipper 

1 5 and the shipment as can be seen below in Table 2. 



Table 2 - Shipper Profile 



DATA ELEMENT 


WIDT 
H 


TYPE 


DESCRIPTION 


Shipper ID 


10 


N 


Uniquely identifies a legal entity using a single 
BOL system, assigned by the CP 40. 


Account ID 


16 


N 


Account # assigned to shipper 20 by issuing 
processor 54. 


Shipper Name 


32 


A/N 




Shipper Address 1 


32 


A/N 


Headquarters Address 


Shipper Address 2 


32 


A/N 




Shipper City 


28 


A/N 




Shipper 
State/Province 


3 


A/N 




Shipper Country 


3 


A/N 




Shipper Contact 


32 


A/N 




Shipper Phone 


10 


N 




Open Date 


8 


N 


Supplied by CP 40 when record is built. 
YYYYMMDD format 
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DATA ELEMENT 


WIDT 
H 


TYPE 


DESCRIPTION 


Date of First Activity 


8 


N 


A . j* 11 1* J 1 /"IT* A r\ 1 JT* i 

Automatically supplied by CP 40 when first 
BOL record is received by CP 40 - 
YYYYMMDD format 


Date of Last Activity 


8 


N 


Automatically updated by CP 40 every time a 
BOL record is processed 


Current Status 


4 


A 


Valid values are OPEN, CLSD, HOLD. 
Automatically updated on effective date if 
effective date was pre-entered or as part of on- 
line transaction when effective date is set to 
today. 


Current Status Date 


8 


X T 

N 


Automatically updated by system when 
current status field is updated, YYYYMMDD 
format 


Pending Status 


4 


A 


TT '111 j_ j_ 1 " 1 1 _ _ ATiP\T 

User will key status, valid values are OPEN, 

OT\ TTAT TA 

CLSD, HOLD 


Effective Date 


8 


N 


Default to today's date with user ability to 
overnde to a future date. YYYYMMDD 
format 


Last update date 


8 


N 


Automatically stamped by CP 40 


Last update time 


4 


N 


Automatically stamped by CP 40. HHMM 
format 


Last Update User 


8 


A/N 


Automatically pulled from user profile by CP 
40. 



An authorized carrier profile list identifies information regarding the carrier 22 
and the shipment transaction as can be seen below in table 3. Included in the carrier 
profile is a merchant number that a paying processor 54 assigns to the carrier 22. Each 
5 carrier 22 can have multiple merchant numbers if desired. This allows carrier flexibility 
to assign different merchant numbers for different regions or different shippers. This 
flexibility facilitates the carrier's business management process. It is not known of 
existing systems that provide such flexibility. 



Table 3 - Carrier Profile 





DATA 


DATA 




COLUMN NAME 


WIDT 


TYPE 


DESCRIPTION 




H 
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COLUMN NAME 


DATA 
WIDT 
H 


DATA 
TYPE 


DESCRIPTION 




A 
4 


A /NT 
A/ IN 


4 cnaracicr cocic isidi uniciueiy lucziuiics 

a lw/aITlcr Z^. 


— r — r — — — 

Merchant Number 


1U 


XT 


x dying prUC/CboUI JH- ao alalia LU CaL/Il 

CI 1*1*1 f^v 


Carrier 22 Name 


32 


A/N 


DBA name of Carrier HQ 


Carrier Address 1 


19 


A /NT 
A/IN 




Carrier Address 2 


dL 


A /NT 




Carrier City 


9Q 
Zo 


A /NT 




Carrier 

State/Province 


3 


A/N 




Carrier Country 


3 


A/N 




Carrier Contact 




A /NT 
A/ IN 


iName 01 primary contact at v^arner ri\i 


Carrier Phone 


10 


N 


Phone number of primary contact at 
Carrier HQ 


Open Date 


8 


N 


Automatically supplied by CP 40 when 

_ i * _ 1 ' 1 4_ ~\7"\7"\7"\7~~\ AT\T\ -C^. -t~»-t ,n +■ 

record is built. Y Y Y Y MJVLDD tormat 


Date of First 
Activity 


8 


N 


Automatically supplied by CP 40 when 
first BOL record is received by system 
on this Carner 22 - Y Y Y Y JVUVLDD 
format 


Date of Last Activity 


8 


N 


Automatically updated by system every 
time a BOL record is processed for this 
Carrier 22 


Current Status 


4 


A 


Valid values are OPEN, CLSD, HOLD. 
Automatically updated on effective date 
if effective date was pre-entered or as 
part of on-line transaction when 
enective ciate is set to Lou.dy. 


Current Status Date 


8 


N 


Automatically updated by CP 40 when 
current status field is updated, 
YYY yivijvlijjj iormat 


Pending Status 


4 


A 

A 


User will key status 


Effective Date 


8 


N 


Default to today's date with user ability 
io override to a iuiure cuiic. 
YYYYMMDD format 


Last update date 


8 


N 


Automatically stamped by CP 40 


Last update time 


4 


N 


Automatically stamped by CP 40 
HHMM format 


Last Update User 


8 


A/N 


Automatically pulled from user profile 
lists by CP 40 
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An authorized shipper/carrier profile list identifies information regarding valid 
shipper carrier combinations as can be seen below in table 4. 



Table 4 - Shipper/Carrier Profile 



COLUMN NAME 


DATA 
WIDT 
H 


DATA 
TYPE 


DESCRIPTION 


Shipper ID 


10 


N 




Carrier SCAC 


4 


A/N 




Merchant Number 


10 


N 


Assigned by Paying processor 54. If 
blank use default value from carrier 
profile. 


Proof of Delivery 


1 


A 


"Y" for POD to be required, "N" for POD 

not rprniireri 


Type of POD 


4 


A 


Identifies in what manner the POD is to 
he received 


Auto close days 


2 


N 


Number of days after which the 
transaction will close and be paid to the 
Carrier 22 regardless of whether or not 
POD has been posted. 




0 
o 


"NT 


Aiitnm Pitifallv Qiirvnli pn hv iT* 40 wnpn 

/^\Al\JLlLClLl\-/CLLLy jiXLJlJ LL\j\JL UV V^l tu W llvll 

record is built, YYYYMMDD format 


Date of First 

A cti vi tv 
zi.^/ ti v 1 l y 


8 


N 


Automatically supplied by CP 40 when 
fir^t ROT, record is received bv svstem - 

lit J * J J J. V V\-/JL VI AO JL Vvvl T v\_l. v J w > Olvlll 

YYYYMMDD format 


Date of Last 
Activity 


8 


N 


Automatically updated by CP 40 every 
time a BOL record is processed 


Cnrrpnt ^ItatiiQ 


4 


A 


Valid values are OPEN CLSD HOLD 
Automatically updated on effective date if 
effective date was pre-entered or as part 
of on-line transaction when effective date 
is set to today. 


Current Status Date 


8 


N 


Automatically updated by CP 40 when 
current status field is updated, 
YYYYMMDD format 


Pending Status 


4 


A 


User will key status 


Effective Date 


8 


N 


Default to today's date with user ability to 
override to a future date. YYYYMMDD 
format 


Last update date 


8 


N 


Automatically stamped by CP 40 
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COLUMN NAME 


DATA 
WIDT 
H 


DATA 
TYPE 


DESCRIPTION 


Last update time 


4 


N 


Automatically stamped by CP 40 HHMM 
format 


Last Update User 


8 


A/N 


Automatically pulled from user profile 
lists 



An authorized shipper access terminal profile identifies the shipper 20 as well as 
the shipping dock. A shipper has a separate shipper access terminal profile for each 
5 dock. The central processor 40 assigns a different dock ID for each dock. The 
information included in the access point profile is listed below in table 5. 



Table 5 - Access Terminal Profile 



COLUMN NAME 


WIDT 
H 


TYPE 


DESCRIPTION 


Shipper ID 


10 


N 


Uniquely identifies a legal entity using a 
single BOL system 


Dock ID 


3 


N 


Uniquely identifies a particular physical 
dock location with a shipper ID. 


Account ID 


16 


N 


Issuing Processor 54 assigns. Defaults 
from shipper profile, can be overridden by 
shipper. 


Dock Name 


32 


A/N 


DBA name of dock originating BOL 


Dock Address 1 


32 


A/N 


Street address of dock originating BOL 


Dock Address 2 


32 


A/N 




Dock City 


28 


A/N 




Dock State/Province 


3 


A/N 




Dock Country 


3 


A/N 




Dock Contact 


32 


A/N 




Dock Phone 


10 


N 


To be used for reporting against completion 
transaction 


Open Date 


8 


N 


Automatically supplied by CP 40 when 
record is built. YYYYMMDD format 


Date of First 
Activity 


8 


N 


Automatically supplied by CP 40 when first 
BOL record is received by system - 
YYYYMMDD format 
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COLUMN NAME 


WIDT 
H 


TYPE 


DESCRIPTION 


Date of Last 
Activity 


8 


N 


Automatically updated by CP 40 every 
time a BOL record is processed 


Current Status 


4 


A 


Automatically updated by CP 40 on the 
effective date if effective date was pre- 
entered or as part of the on-line transaction 

if the effective date is changed to today. 
Valid values are OPEN, CLSD, HOLD 


Current Status Date 


8 


N 


Automatically updated by CP 40 when 
current status field is updated, 
YYYYMMDD format 


Pending Status 


4 


A 


User will key status 


Effective Date 


8 


N 


Default to today's date with user ability to 
override to a future date. YYYYMMDD 
format 


Last update date 


8 


N 


Automatically stamped by CP 40 


Last update time 


4 


N 


Automatically stamped by CP 40 HHMM 
format 


Last Update User 


8 


A/N 


Automatically pulled from user profile lists 



The central processor 40 authenticates 408 the transaction information by 
comparing elements of transaction information with the authorized user profile lists. 
The elements of the transaction information used for authentication include; the identity 
5 of the shipper, the identity of the shipper's dock, and the identity of the carrier. If the 
authentication is successful, the central processor 40 assigns 410 a payment 
identification number (payment ID) to the transaction information and stores 412 the 
transaction information in the data storage unit 42. The payment ID is a unique key for 
the transaction record which the central processor 40 uses to centrally track the 

1 0 transaction. The payment ID includes specific information regarding the shipment 
transaction including; the shipper identification number, the BOL number, and the 
shipping date. The advantage of the payment ID is that it allows the central processor 
40 to more efficiently and accurately track the different actions occurring within the 
system. The payment ID can be referenced to the specific identification numbers that 

1 5 any of the users may assign. The payment ID is now considered "open". Open is a 
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term used to signify that the shipper 20 has transferred the goods to the carrier 22, and 
the carrier 22 has not yet completed the shipment. 

If the authentication is unsuccessful, the central processor 40 stores 414 the 
invalid transaction in a suspense file in the data storage unit 42. When an invalid 
5 transaction is stored, a notification is sent which indicates that an error has occurred and 
is in need of further review and correction. Once the error is corrected, the corrected 
transaction may be sent into the normal process path. 

The central processor 40 sends the authenticated transaction information, 
including the shipper identity and the cost of the shipment, to an issuing institution 44 

1 0 for authorization. FIG. 5 is a block diagram illustrating an example flowchart for 
programming the issuing processor 45 of FIG. 1 to perform an authorization check 
according to the present invention. The issuing institution 44 contains an issuing 
processor 45. The issuing processor 45 maintains accounts for one or more shippers. 
Each account includes information regarding credit limits, open authorizations, unpaid 

1 5 balances, and the resulting open-to-buy. Open-to-buy measures the unused credit limit. 

The issuing processor 45 receives 502 the authorization request from the central 
processor 40. The issuing processor 45 compares 504 the authorization request to the 
open-to-buy of the shipper and attempts to approve 506 the request. If the shipper 20 
has enough open to buy, the issuing processor 45 approves the authorization request. 

2 0 The issuing processor 45 stores 507 the approved authorization request and decreases 
508 the open-to-buy. The issuing processor 45 sends 510 the authorization approval to 
the central processor 40 and the central processor 40 updates the records in the data 
storage unit 42. If the authorization is successful, the payment ID is considered 
"authorized". If the authorization is unsuccessful, the issuing processor 45 sends 512 an 

2 5 authorization decline to the central processor 40. 

After the goods are delivered to a receiver, the payment ID must be "closed". 
Closed refers to providing proof of delivery (POD) of the shipment in order to complete 
the shipment transaction. POD includes the identity of the shipper, the BOL number, 
the carrier invoice number, the delivery date and time, the person acknowledging 
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receipt, and the condition of the shipment. A carrier processor 46 receives the POD and 
sends the information to the central processor 40. 

In one embodiment, the carrier processor 46 is a conventional bar code reader. 
The bar code reader is used by the carrier 22 to read a bar code on the shipment. The 
bar code reader sends the POD information to the central processor 40. 

In an alternative embodiment, the carrier processor 46 is a voice response unit 
48 (VRU). FIG. 6 is a block diagram illustrating an example flowchart for 
programming the VRU 48 according one embodiment of the present invention. In this 
embodiment, the central processor 40 extracts an open payment ID from the data 
storage unit 42. The central processor 40 sends information relating to the open 
payment ID, including the BOL number and the shipper ID, to the VRU 48. The VRU 
48 receives 602 the open BOL number. 

A standard touch-tone telephone is used to access the VRU 48. While the 
location of the telephone is not critical, locating it at the receiver's premises promotes 
efficiency, convenience, and accuracy. It is convenient and efficient because the carrier 
22 can call the VRU 48 at the exact time the shipment is delivered. It is accurate in that 
the phone number of the receiver, automatically captured by the VRU 48, will identify 
where and when the call was made. 

The VRU 48 prompts 604 the carrier 22 for the shipper ID. The VRU 48 
receives 606 the shipper ID and attempts to match 608 the entered shipper ID with an 
open shipper ID. If the shipper ID is matched, the VRU 48 prompts 610 the carrier 22 
for the BOL number. The VRU 48 receives 612 the entered BOL number and attempts 
to match 614 the combination of the entered BOL number and shipper ID with an open 
BOL number and Shipper ID. If the BOL number and shipper ID combination is 
matched, the VRU 48 prompts 616 the carrier 22 for condition of shipment The VRU 
48 receives 618 the condition of shipment and sends 620 the POD information which 
includes BOL number, the shipper ID, and the condition of the shipment to the central 
processor 40. 
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If the VRU 48 cannot match either the shipper ID and the BOL number, the 
VRU 48 prompts 622 the carrier 22 to either try again or routes 624 the carrier 22 to 
customer service where the problem can be resolved. 

FIG. 7 is a block diagram illustrating an example flowchart for programming the 
5 central processor 40 of FIG. 1 generating a deposit file according to the present 

invention. The central processor 40 receives 702 the matched BOL number, the shipper 
ID, and the condition of the shipment from the carrier processor 46. The central 
processor 40 validates 704 the incoming data to ensure that it is error free and properly 
formatted. The central processor 40 extracts 706 the open payment ID from the data 
1 0 storage unit 42. The central processor 40 authenticates 708 the matched BOL number 
with an open payment ID. If the BOL number and payment ID are authenticated, the 
payment ID is considered complete. The central processor stores 710 the completed 
transaction and corresponding payment ID in the data storage unit 42. If authentication 
is unsuccessful, the central processor 40 stores 712 the information in a suspense file 
1 5 where the problem can be manually resolved as discussed above. 

A payment ID can be completed by the above manner or a payment ID can 
expire. A payment ID expires when a pre-programmed number of days have elapsed 
since the shipping date. This preprogrammed number of days is defined as auto close 
days in the data storage unit 42. A particular transaction is identified by the shipper and 
2 0 carrier to expire on a specific date, the effective date, whether or not the proof of 

delivery is received. On the effective date, the payment process begins. This has the 
advantage that the carrier 22 will be paid for every shipment carried. Payment to the 
carrier 22 is expedited if proof of delivery is received. 

The central processor 40 periodically extracts 714 from the data storage unit 42 

2 5 the transactions that are listed as "completed and authorized" or "expired and 

authorized." The central processor 40 sorts and batches 716 the transactions by the 
merchant number. The central processor 40 generates 718 a deposit file 50 for those 
authorized transactions that are completed or expired and which have not been 
previously extracted. In a particular application, one deposit file 50 is created for all 

3 0 transactions completed by each carrier. The deposit file 50 is formatted so that it is 
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compatible with the paying processor's 54 format. The deposit file 50 includes the 
payment ID, the account ID, the carrier identity, the BOL number, the destination city, 
the destination state, the destination zip code, and the cost of shipment. The cost of the 
shipment represents the amount that is owed by the shipper 20 and payable to the carrier 
5 22. 

The central processor 40 performs 720 a general integrity check on the deposit 
file 50. The integrity check includes: ensuring that the payment ID has been authorized, 
ensuring that the BOL is completed or expired, and ensuring that payment has not yet 
occurred for the particular payment ID. 

1 0 If the central processor 40 validates the deposit file 50, the processor 40 sends 722 the 
deposit file 50 to a paying processor 54 of a paying institution 52. In a particular 
application, the deposit file 50 is conventionally sent via a telephone transmission. The 
paying institution has a paying processor 54 which processes financial information and 
maintains financial accounts for the carrier 22. The paying processor 54 is generally 

15 designed to process financial information. The paying institution 52 maintains one or 
more accounts for each carrier 22. 

FIG. 8 is a block diagram illustrating an example flowchart for programming the 
paying processor 54 of FIG. 1 according to the present invention. The paying processor 
54 receives 802 the deposit file 50 and sends 804 a confirmation message to the central 

2 0 processor 40 that the deposit file 50 was received. 

The paying processor 54 validates 806 the incoming deposit file and generates 
808 payment to the carrier 22. The paying processor 54 tenders 810 payment to the 
carrier 24 and sends 812 this information to the central processor 40 so that the central 
processor 40 can update the data storage unit 42. In a particular application, the paying 

2 5 processor 54 tenders payment by directly paying the carrier 22. In an alternative 

embodiment, the paying processor 54 sends the payment to the carrier's bank 
conventionally through the Federal Reserve's Automated Clearing House. 

One advantage associated with the generation of payments to the carrier 22 is 
that the carrier 22 is paid relatively soon after the carrier 22 has completed the shipment. 

3 0 This provides the carrier 22 with improved cash flow and reduces the carrier's working 



capital requirements. Another advantage is that the carrier 22 does not have to audit or 
rate the payment that saves time and money. This streamlined approach reduces the 
carrier's administrative costs associated with processing a payment. 

The paying processor 54 generates 814 a systems bill for the carrier 22. This 
5 systems bill represents the amount the carrier 22 owes for the service provided by the 
system of the present invention. The paying processor 54 sends 816 the systems bill to 
the carrier 22. The paying processor 54 sends 818 the systems bill information to the 
central processor 40 where the information is stored in the data storage unit 42. The 
paying processor 54 delivers 820 the paid shipment transactions to the issuing processor 

10 45 of the issuing institution 44. 

The issuing institution 44 maintains one or more accounts for the shipper 20 and 
extends and manages credit to the shipper 20. The issuing processor 45 maintains the 
amount paid to each carrier 22 on behalf of each shipper 20. FIG. 9 is a block diagram 
illustrating an example flowchart for programming the issuing processor 45 of FIG. 1 to 

15 credit a transaction according to the present invention. The issuing processor 45 

receives 902 the paid transactions from the paying processor 54. The issuing processor 
45 retrieves 904 the approved authorization list and compares 906 the authorization list 
with the paid transactions. The issuing processor 45 attempts to match 908 the paid 
transactions with an authorized transaction. If a match is made, no change is made to 

2 0 the open to buy. If a match is not made, the issuing processor 45 decreases 910 the 
open to buy. 

The issuing processor 45 posts 912 the cost of shipment for all paid transactions 
to the shipper's account thereby increasing the balance due from the shipper 20. The 
issuing processor 45 periodically bills 914 the shipper 20 for the posted financial 

2 5 transactions paid on behalf of the shipper 20 and periodically receives 916 payment 

from the shipper 20. When the issuing processor 45 receives payment, the processor 45 
posts payment to the shipper's account and increases 918 the open-to-buy. 

The issuing processor 45 communicates with the central processor 40 and sends 
information regarding shipper 20 payment and billing. The central processor 40 updates 

3 0 the data storage unit 42 with this information. 
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In an alternative embodiment, the paying institution 52 is incorporated into the 
issuing institution 44. This results in one processor performing the functions of the 
issuing processor 45 and the paying processor 54. 

A further advantage of the computer processing system for a shipment 
5 transaction involving a shipper and a carrier is that the data storage unit 42 and central 
processor 40 interface to store and provide value-laden information to the users of the 
system. The central processor 40 provides a security check for all information entering 
and leaving the data storage unit 42. The central processor edits incoming files and 
provides on-line alarms for duplicate files, stale dated files, out of balance files, and 
1 0 files with corrupt data. The central processor 40 maintains a suspense file in the data 
storage unit 42 where incoming invalid transaction information and unmatched proof of 
delivery information are stored. With a centrally located suspense file, the problem 
resolution process is more efficient. 

The central processor 40 maintains data views and tables and stores this 
1 5 information in the data storage unit 42. The central processor 40 maintains a BOL 
Header Table for each BOL number that generally includes a summary of all 
information relating to that shipment transaction. This information is shown in the table 
6 below. The source of the particular data element is indicated in column four of table 
6. 

20 

Table 6 BOL Header Data Elements 



Data Element 


Length 


Type 


Source 


Purpose 


Shipper ID 


10 


N 


CP 40 


Record ID 


Dock ID 


3 


N 


CP 40 


Record ID 


Account ED 


16 


N 


CP 40 


Record ID; reporting 


Bill of Lading # 


15 


AN 


Shipper 


Record ID 


Ship Date 


8 


N 


Shipper 


Record ID, reporting 


SCAC 


4 


A 


Shipper 


Alternate index, identifies 
Carrier 


Merchant # 


10 


N 


CP 40 


Alternate index, for CP 40 
usage 


Vendor # 


10 


N 


Shipper 


Alternate index, allows 
Shipper to specify its vendor 
number for a given carrier 
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Data Element 


Length 


Type 


V S\ 1 g »/!/] 




Customer Number 




XT 
IN 


o nipper 


/TullCIIlctLC lilU.CA ? dllU W o 

^Ihinnpr to snpnifv it's 

customer number for a given 
receiver 


i^usiomer r\j tt 


1 S 


AN 


kjlllLJL/ vl 


Alternate index renortins 


Shipper Order # 


15 


AN 


Shipper 


Alternative Index 


v encior uraer 


1 J 


rVLN 


ollippci 


13 pnrrrtinp alternate locator 

JVvUUl llllii ? ClltvlllCttV luvatui 


o nipper i>iaiiic 




AN 
nil 


Shinner 


Renortins: 


snipper v^onidc-i 

P pre n~n 




A 

s\. 


Slninnpr 


Claims 


OllippCl JTIlUllt' tt 


15 


AN 


Shinner 


Claims 




10 

1 V 


AN 


Shinner 


Reporting 




20 


AN 


Shinner 


Reporting 


oldlC 


9 


A 


Shinner 


Reporting 




Q 

y 


N 


Shinner 


Renortine 


jjivision i^ocie 


9 


AN 


SiViinnPT 


Renortinff 


IVCierCIlUC 13/ rrl 


1 S 


AN 


Shinner 


Consolidated Shipments 


Reference B/L #2 


15 


AN 


Shipper 


Consolidated Shipments 


rceierence rj/i^ tf d 




AN 


^Viinnfi* 


Consolidated Shinments 


Bill of Lading Type 


1 


AN 


Shipper 


Reporting 


onrpment Moue 




rYTN 


oinppci 


T TT TT RAT ATR 


Inbound, Outbound 
Flag 


i 
i 


A XT 


oiiippci 




r repaid, v^oneci 

Th 1 q rr 

ridg 


i 
i 


AN 


^IViinnpr 
oiiippci 


1? pnortinff 


v^wu ridg 


1 

i 


AN 


Shinner 


Renortinff 

jlvvu X \,xxx^~ 


V^wU r\IIlUUIlL 


0 1 

y 


AN 


Shinner 


Renortin^ 


o nip men i v di uc 


y 


AN 


Shinner 

kJ 111 L7 vl 


Renortine* claims 






AN 


Shinner 

UllllJL/ VI 


Renortins: Claims 


i rdiier/\^dr tt 


i s 


AN 


thinner 


Renortins:* claims 

IWUvi. till W « Vli+IAAAW 


Trailer/Car Seal # 


15 


AN 


Shipper 


Reporting; claims 


import, export r lag 


i 
i 


AM 


^IhiTYnpf 

OIllL/^Jvi 


1? pnortmp' 

IvvUvl tlllg, 


ft MOpS 


9 


XT 


^khinnpf 
OiiippC/i 


13 pnorrttiP" 


Stop Off Charges 


7.2 


AN 


Shipper 


Reporting 


Rated Freight 
^ndrges 


Q 9 


A XT 


omppcr 


Pd\rmpnt rpnnrtincr 
r^ctyiiiC'iiL, icpuiLiiig 


Cube Dimensions 


5 


N 


Shipper 

x Jr 


Reporting 


Shipment "as 
weight" 


7.2 


N 


Shipper 


Reporting; claims 


Accessorial Charges 


7.2 


AN 


Shipper 


Payment, reporting 


Total Freight Chgs 


9,2 


AN 


Shipper 


Payment, reporting 
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Data Element 


Length 


Type 


Source 


Purpose 


J-/CaUIlaLlUIl INcUIlC 


ZD 


A1N 


ompper 


Jtvepomng 


Destination City 


20 


AN 


Shipper 


Reporting 


jjesimaiion oiaie 


L 


A 
A 


Shipper 


Reporting 


i^esimaiion zjp 


Q 

y 


XT 

JN 


Shipper 


Reporting 


ue&LiridLion j\±Gd 


1 


IN 




Shipper 


— — ; — ; 

Reporting, verification 


L-'CbLlIlallUIl JTlCllA 


D 


XT 
IN 


ompper 


Kepomng, veriiication 


-L'CoLlIlaLUJIl .TIlUIlG 


A 


IN 


ompper 


Keponmg, veriiication 


A/T 1 1 rrp* 


D 


XT 
IN 


ompper 


xceporxing 




1 9 




v^Jr 4U 


inquiry 


OIlip l^ctLC 


C 
o 


XT 


o nipper 


i^ne cycie uacKing 


CP 40 Receipt Date 


8 


N 


CP 40 


Life cycle tracking 


oioidgc mserx uace 


Q 
O 


AT 
IN 




Life cycle tracking 


VRU Extract Date 


8 


N 


CP 40 


Life cycle tracking 


Authorization Date 


o 

8 


JN 


CP 40 


Life cycle tracking 


Authorization # 


6 


AN 


Issuing 
rroc.4j 


From authorization response 
ieeu 


Auth Response 
Code 


z 


A XT 

AJN 


Issuing 
Proc.45 


Jrrom autnonzation response 
feed 


uenvery uaie 


Q 
O 


XT 

JN 




Life cycle tracking 


Completion Date 


8 


N 


CP 40 


Life cycle tracking 


Deposit Extract Date 


O 

0 


XT 

N 


CP 40 


Life cycle tracking 


Settlement Date 


8 


N 


Paying 
Proc.54 


From Settlement record 


Settlement DDA # 


12 


AN 


Paying 
Proc, 54 


From Settlement record 


Shipper Billing Date 


8 


N 


Issuing 
Proc.45 


From statement billing file 
ieed for life cycle tracking 


Delivery Area Code 


3 


N 


Carrier 
Proc 


POD tracking, claims 


Delivery Prefix 


5 


XT 

IN 


Carrier 
Proc.46 


POD tracking, claims 


Delivery Phone 


A 

4 


XT 

JN 


Carrier 
Proc.46 


POD tracking, claims 


Receiver Name 


20 


A 


Carrier 


POD tracking, claims 


Receipt Condition 


i 


A 


Carrier 
Proc.46 


Quality of service tracking, 
claims 


POD ID 


15 


AN 


Carrier 
Proc.46 


Provided by carrier 22(such 
as FedEx, UPS) who has 
accepted POD system 
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In addition, the central processor 40 maintains BOL line item details from the 
transaction information. The BOL line item details generally consist of information 
relating to the goods of the shipment as can be seen below in table 7. 

Table 7 - BOL Line Item Detail Data Elements 

5 



Data Element 


Length 


Typ 

e 


Source 


Purpose 


Shipper ID 


16 


N 


CP 40 


Record ID 


Bill of Lading # 


15 


AN 


Shipper 


Record ID 


Ship Date 


8 


N 


Shipper 


Record ID 


Product Description 


28 


AN 


Shipper 


Reporting, claims 


Product ID 


8 


AN 


Shipper 


Reporting, claims 


Product Value 


7.2 


$N 


Shipper 


Claims 


Haz Mat Flag 


1 


AN 


Shipper 


Reporting, claims 


Item Weight 


7.2 


N 


Shipper 


Reporting, claims 


Total Pes 


5 


N 


Shipper 


Reporting, claims 


Item "as weight" 


7.2 


N 


Shipper 


Reporting 


Unit of Measure 


4 


AN 


Shipper 


Reporting, claims 


Accounting Code 


25 


AN 


Shipper 


Reporting 


Item Freight 
Charges 


7.2 


N 


Shipper 


Reporting, claims 



In the example system application of FIG. 1, the carrier 22 will not have access 
to the BOL line item product value, but will be able to see the line item freight charges. 

10 A further advantage of the shipment transaction system of FIG. 1 is that the 

system allows multiple users to obtain information about the same shipment from the 
same source. Since the system supplies information from the same source, all users will 
obtain the same information at the same time. This advantage of timeliness does not 
exist in current systems. Existing systems are not known to provide a single source of 

1 5 up-to-date information regarding multiple shipment transactions. 

In an alternative embodiment, multiple users access the shipment information 
via the central processor 40. The shipment information is stored in the data storage unit 
42. The central processor 40 is electronically linked to a multitude of user stations. The 
link between the central processor 40 and a user station allows for conventional two- 
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way communication. The user station is a standard personal computer comprising of a 
video display, a keyboard, a central processor, and a modem link. A user initiates a 
request for information by accessing the central processor 40 using the personal 
computer. When the user is logged into the central processor 40, the central processor 
5 40 prompts the user to enter a password. 

The central processor 40 provides a security check on all information requests. 
The security check is programmed such that the shipper 20 and carrier 22 are restricted 
to accessing only their own data. In addition, the processor 40 is programmed such that 
unauthorized parties are denied access. 

1 0 The central processor 40 receives informational requests from the user. The 

central processor 40 accesses the data storage unit 42 and extracts the requested 
information and transmits the information to the user's station. The advantage of such 
an information service is clear. Users will be able to obtain current information 
regarding a shipment transaction. 

15 In a particular application, once a user has access to the system, the central 

processor 40 will prompt the user for a range of dates of interest including the current 
day, the previous day, monthly total, yearly total, or a specified date range. The central 
processor 40 displays the transaction information, freight amounts, shipment costs, total 
weight, and cost per pound for various types of transactions including: transactions 

2 0 added to the data storage unit, transactions with proof of delivery, transactions that have 
expired, transactions in the suspense file, transactions paid to carrier, transactions in 
transit, transactions declined, and transactions approved. 

The central processor 40 allows user's to request a particular transaction by 
entering any one of a multitude of transaction elements. The central processor 40 

2 5 identifies a particular transaction with reference to the BOL number, the shipper' s 

customer number for the receiver 22, the payment ID, the carrier's customer number for 
the shipper 20, the merchant number, the account ID, the receiver's order number for 
the shipper 20, the shipper's order number for the BOL number, or the shipping date. 
This ensures compatibility between the user reference numbers such that the user can 

3 0 access information using their unique reference number assigned to the transaction. 
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The example application has additional advantages. The central processor 40 
provides to all authorized users the ability to generate custom analysis of their own data. 
This has the advantage of giving the carrier 22 the ability to extract payment data 
needed to automatically post his accounts receivable system. This is an advantage over 
5 existing systems that rely on manual distribution of payment against the account 
receivable system. Similarly, the shipper can extract payment data and automatically 
post his accounts payable which closes out the individual accounts payable due to each 
carrier. An advantage stemming from this automated system is that the shipper 20 does 
not need a paper invoice in order to have proof of delivery. The shipper 20 accesses the 

1 0 central processor 40 and verifies which shipments have been delivered by a particular 
carrier 22. Similarly, the carrier 22 accesses the central processor 40 to find out which 
transactions have been paid out by the shipper 20. This informational system removes 
much uncertainty from the shipment process that promotes more efficient use of 
available resources such as working capital, transportation, and personnel. 

15 In a particular application, the central processor 40 generates standard shipment 

transaction summary reports and provides appropriate access to the reports by various 
users. These reports include a transaction inventory control report, an open aging 
summary report, a suspense inventory control by source report, and a suspense 
inventory aging summary report. The central processor 40 uses the security profiles to 

2 0 determine which subset of transaction records will be summarized for each user. For 
example, the shipper 20 has access only to that shipper's reports. 

The inventory control report provides control totals of BOL numbers, 
merchandise value, and freight value. There are key control points including: starting 
inventory position, new BOL's from shippers, BOL's closed since the last report by the 

2 5 different methods discussed for closing BOL numbers, BOL's re-opened since the last 

report by manual proof of delivery override via customer service, BOL's canceled since 
the last report, and the ending inventory position. 

The open aging summary report contains those BOL numbers that have not been 
delivered. In addition, the freight value and merchandise value for each shipper ID and 

3 0 Dock ID are supplied for distinct age groups. The age groups include groupings by 
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consecutive days since the shipping date and one group for 10 days past the shipping 
date. The suspense inventory control by source report includes merchandise and freight 
value amounts of transactions in the suspense file. Several control points for the 
suspense inventory control include: starting inventory position, new inventory added 
5 since last report, inventory cleared since last report, inventory deleted since last report, 
inventory undeleted since last report, and ending inventory position. The suspense 
inventory aging summary report provides an aged summary of suspense files including 
the merchandise and freight value of items that are in the suspense file by original 
receipt date. 

1 0 The central processor 40 generates detailed reports including: the inventory 

aging detail report, the suspense inventory aging detail report, and the declined item 
aging detail report. The detail reports are viewed by either the shipper ID/Dock ID/ 
account ID combination or by the carrier ID/merchant number combination. The 
inventory aging detail report lists the open BOL numbers sorted by the days in 

1 5 inventory, the shipper ID combination, and the BOL number. The inventory detail 
report lists the merchandise and freight value associated with each open BOL number. 
The suspense inventory aging detail report lists open BOL numbers by source and 
receipt date. Several fields are displayed including: shipper ID, dock ID, account ID, 
BOL number, carrier ID, freight value, and the merchandise value. The declined item 

2 0 aging detail report allows users to research the cause of exception items and lists the 
shipper ID combination, ship date, authorization time, BOL number, shipper invoice 
number, merchant number, and freight value. The declined item aging detail report is 
viewed by either shipper ID/dock ID/account ID combination, or by carrier ID/merchant 
number combination. 

2 5 The central processor 40 generates two reports that reference declined 

authorizations. These reports include the declined item summary report and the 
declined item aging report. The declined item summary report summarizes information 
regarding the declined authorization. The declined item aging report summarizes the 
information regarding the declined authorization by the shipping date. 
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Referring now to FIGs. 1 OA- IOC, according to the present invention, example 
transactional processes for implementing ship transactions are shown in the form of 
flow diagrams. FIG. 10A illustrates a manner in which accounts for shippers and 
carriers can be set up in a database for processing shipment transactions by the main 
5 CPU system running the operations. 

The approach shown in FIG. 10A includes five levels, with each level applicable 
to both the shipper and the carrier. At level 1010, an account is merely established for 
the shipper/carrier. Setting up the account and defining the company profile is 
administered by the central operators. For instance, if a credit institution, such as a bank 

1 0 with a credit division, owns and/or is operating the main CPU and defining 

communication access to the system, an agent of the credit institution administers these 
tasks. At level 1014, a company profile is established on the main CPU for the 
shipper/carrier. A typical company profile includes, among other particulars, contact 
information, facility locations, invoicing/debit/credit agreements for system use, and 

1 5 security information. Defining a company profile permits the shipper/carrier to be a 
user of the system with access to information processed by the main CPU for the 
shipper/carrier. At level 1016, a profile for the system administration is established to 
refine the shipper/carrier's access to the information associated within its company (the 
shipper or carrier) and organizational unit. At levels 1020 and 1024, the 

2 0 shipper/carrier's administrator defines operational profiles to define how the company 
will use the shipment transaction system. 

According to a more specific implementation, there are specific operational 
profiles and specific user profiles used by the main CPU to execute operations. These 
specific operational profiles fall into five categories: approval policies to define the 

2 5 monetary limits for each particular approver of bills; floor limits to define any rule for 

automatic approval of bills; G/L charts of accounts that are used in the process of 
allocating freight expenses to particular accounts within the company's general ledger 
system; operational filters to define characteristics of the rights of each user of the 
system within the company; and data filters that define business rules that are used to 

3 0 limit the transactions such a user can see. 
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The specific user profiles, which are issued and managed by the company using 
the system, are used by the system to enforce business rules with the company. These 
rules may include, for example, that every user ID: be unique, associated with only one 
organizational unit within only one company, and have only one operational filter and 
5 only one data filter associated with it. Examples of other such business rules include 
establishing that actions performed by the company are binding and that updates to the 
company's profiles be made regularly. 

At levels 1026 and 1028, the main CPU uses the previously defined information 
to establish the user relationships (depicted at level 1026) and to define carrier vendors 
10 or shipper customers, respectively, for the shipper-type company or the carrier-type 
company. 

Using the above information, the main CPU then begins to define trading 
partners and trading parameter data for each shipper and for each carrier. This is 
depicted at level 1034 of FIG. 10A. 

1 5 For additional examples of ways to implement the above-characterized levels, as 

well as other aspects and examples of the various example embodiments, reference may 
be made to the attached Appendix A (Training Guide) and to the attached Appendix B 
(Users Guide). For example, for information relating to the example setup information 
of FIG. 10A, reference may be made to Chapter 1 of attached Appendix B (Users 

2 0 Guide). 

FIG. 10B illustrates an example relationship that may be used in the shipment 
transaction system for processing freight payments. As discussed above in connection 
with FIGs. 1, 2 and 2A, upon receipt of the BOL (block 1040), the main CPU receives 
notification of delivery (block 1042) and the creditor (e.g., financial institution or bank) 

2 5 approves transaction 1044 and authorizes payment (block 1046). Payment is then made 

to the carrier as indicated in block 1048. 

FIG. 10C illustrates example processes for transactional flow, between a carrier 
and a shipper, in an example shipment transaction system referred to as "PowerTrack" ® 
As illustrated in FIG. 10C, work transactions 1050 occur in response to activity input to 

3 0 the system from equipment, such as computers or other data input/output devices, 
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operated by the shipper and the carrier. Such equipment is depicted as shipper items 
1052a, 1052b and carrier items 1054a, 1054b. The main CPU 1056 processes the data 
via Internet communication links, and interfaces with a payment-center CPU 1058 
operated by the creditor/bank. As illustrated, the main CPU 1056 and the payment- 
5 center CPU 1058 exchange data with each other and the items 1052a, 1052b, 1054a, 
1054b to effect proper payment in response to cleared shipment transactions. 

FIG. 1 1 illustrates an example communication path from an architectural 
perspective in which an array of computers and data routers are used in an example 
implementation of a system and method, according another aspect of the present 

10 invention. The computers include gateway-implemented firewalls 1064, 1066 and 

1068, and data routers in the form of hubs H1-H6 (available from 3Com). Each of the 
firewalls 1064, 1066 and 1068, and data routers H1-H6, along with other accessible 
stations in FIG. 11, have unique Internet addresses. The operators controllers 1076 of 
the main CPU 1078 access tier II, which is used to maintain databases for the system, 

15 via a path through the firewall 1066 and directly back through hub H3, or via a path out 
toward hub H2 and back through hub H3. The financial institutional (not shown) 
accesses the system, along with access by the shippers and carriers, via the Internet at 
block 1080. An outside entity, for example, an auditor can also be setup and authorized 
by the system to access information, and this typically occurs via a path through the 

2 0 Internet or the firewall 1064. 

Within tier II, database/servers are maintained in a dual manner to permit for 
execution of programs for actual system use and for user acceptance testing. Business 
logic database/servers 1081 and 1083 store an object oriented program that is used to 
execute the processing in the actual system (1081) and for user acceptance testing 

2 5 (1082). Also for the actual system (1082) and for user acceptance testing (1084), 

database/servers 1082 and 1084 provide web server functions for the Internet access at 
block 1080. Database/server 1085 is used as a background tool and is useful, for 
example, for sending and receiving information between tier II components and the 
main CPU 1078. Database/servers 1089 and 1090 store shipment transaction 

3 0 information for processing in the actual system (1089) and for processing the same data 
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for analytical purposes, for example, in response to inquiries made by the shipper, the 
carrier, the bank, or an outside entity (e.g., an auditor). 

Database/servers 1088, 1089 and 1090 can be used to duplicate the functionality 
of database/servers 1085, 1086 and 1087 for testing purposes. 
5 Database/servers 1091 and 1092 can be used as interactive voice response units 

adapted to be used by carriers to receive information such as delivery notification, as 
discussed previously. 

As mentioned above, for additional details concerning example implementations 
and aspects, and alternative embodiments of the present invention, reference may be 

1 0 made to the attached Appendix A (Training Guide) and to the attached Appendix B 
(Users Guide), each of which forms part of the instant patent application. 

This invention need not be limited to scenarios involving shipment of product 
and the use of physical carriers for transportation of the product or equipment, since an 
important advantage of the invention is to provide the parties involved a mechanism for 

1 5 auditing transaction information to validate that a transaction occurred properly and as 
agreed upon by the parties involved. The present invention also provides for application 
of the validation system in other areas, by way of example only, but should not be 
limited to these transaction scenarios. Telecommunications service vendors or 
telephone operating companies (TELCOs) are interested in providing their services to 

2 0 third party customers but do not wish to add additional infrastructure (more personnel 
and equipment) in order to engage more customers for their services. The TELCO can 
engage the services of an independent system manager that installs the necessary 
hardware and software at the location of the third party customer and is then responsible 
for ongoing service and maintenance of the equipment and software. In return, the 

2 5 system manager is paid a fee by the TELCO for the initial set up and ongoing service 

calls that may be made by the third party customer. These transactions are validated to 
ensure that they were properly completed and then payment is sent to the system 
manager for services rendered. 

In the area of services, vendors that provide a particular service usually secure 

3 0 customers through a network of agents or service providers that work directly with the 
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customers to sign them up for the service. As shown in FIG. 12, a vendor 1220 through 
his vendor processor 1224 initiates the service transaction by acting in conjunction with 
a Service Quotation or Bidding engine (such as a computer-run programmed task) 1230 
to generate a quote for the cost of the service. Vendor processor 1224 sends the quote 
5 to a data processing device 1234 of a vendor access terminal 1232. Similar to the 
shipping scenario, the data processing device 1234 generates transaction information 
and sends the transaction information to a central processor 1240. The central processor 
1240 identifies and centrally tracks the transaction information. A service provider 
processing device 1246 receives proof of delivery or confirmation that the customer has 
1 0 received the service or is now subscribed to the service and this information is sent back 
to the central processor 1240. The central processor 1240 processes and stores all 
pertinent service subscription information in a data storage unit 1242 and allows 
immediate access to this information by the vendor 1220, the service provider 1222, and 
other authorized users. The central processor 1240 interfaces with an improved payment 
1 5 system including an issuing institution 1244 and a paying institution 1252. An issuing 
processor 1245 of the issuing institution 1244 maintains a credit account for the vendor 
1220 and debits the vendor's account for the service provider's fee (cost of setting up 
the customer to be able to deal directly with the vendor; or cost of getting the customer 
subscribed to the service, etc. . .) when authorized to do so. A paying processor 1254 of 
2 0 the paying institution 1252 tenders payment to the service provider 1222. 

In a specific example, a communications services provider assumes the role of 
the vendor for services ranging from telephone to cable (this includes wireless, satellite, 
video conferencing, internet services, video of demand, etc.) and an authorized agent 
assumes the role of the service provider that helps the vendor sign up customers for a 

2 5 fee. The rest of the transaction is similar to the transaction characterized in connection 

with FIG. 12 for auditing and payout purposes. Finally, tables comparable to Tables 1-7 
(see also Table 1A and Tables 11-15) can be developed for the service provider 
locations and identifying information, as well as authorized users profiles, so that the 
auditing and payment operations pursuant to the transactions can be conducted as 

3 0 described in earlier embodiments. 
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FIG. 13 illustrates an example in which the service provider 1320 initiates the 
transaction, pursuant to customer 1321 A request for quote, and generates the transaction 
information that commences the entire transaction. With this system, vendor 1322 can 
verify that the transaction entered into by the service provider has indeed taken place 
5 and that the customer is satisfied before payment is authorized to the service provider. 
Specifically, the purchase order is processed through processor 1324 that acts in 
conjunction with quotation generating engine 1330 (such as a computer-run 
programmed task). Processor 1324 can simultaneously conduct a credit check of 
customer 1321 A as per instructions of vendor before any transaction is formally entered 

10 in the system. Quotation generating engine 1330 generates a quote for the customer 

with the parameters of the service (which may also include a product purchase as part of 
the package) that he is subscribing to. By way of example, if the transaction is for 
cellular phone service, engine 1330 generates a quote for the cost of the monthly 
service, rate per minute, cost of the initial phone purchase, any weekend discounts, etc. 

1 5 Typically, the quotation engine may be a combination of application software and 
hardware (local PC or server; or a server that is remotely accessed) that contains the 
quotation algorithm and database that the user (service provider or vendor/subvendor) 
needs to generate a formal quote for the customer while initiating part of the transaction 
in the system. The engine 1320 accepts data like: name of prospect customer, address, 

2 0 phone number, # of users, type of service desired, billing particulars, credit history 

evaluation, social security numbers, etc.. The next step can include the generation of a 
customer profile (which can include information on the service provider and his 
location) and identification/customer number that can be used for tracking purposes by 
the vendor (or subvendor). This customer I.D. number can be used later to track 

2 5 payment to service provider. The quotation algorithm and database within engine 1330 

(usable by service provider 1320) can remain static for a fixed period of time, can be 
changed at regular or agreed upon intervals or can be coupled real-time to the vendor's 
database to allow for up to the minute rate changes, special discounts or promotional 
programs that may be applicable. Line 1331 indicates the coupling that can exist 

3 0 between engine 1330 and vendor 1322, that may be hardwired, wireless, through a 
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network, internet, satellite or any other mechanism or system that will allow for one or 
two way coupling and communication between the vendor and the service provider. 

Assuming that all details of the initial transaction are in order, processor 1324 
sends the complete purchase information to data processing device 1334 of access 
5 terminal 1332; processing device 1334 then sends the transaction information to central 
processor 1340. Vendor processing device 1346 receives proof of delivery of service 
provided, or confirmation that the subscriber of the service has met all of the acceptance 
criteria, and that he is now ready to be connected to the system (e.g. cellular phone 
system). Central processor 1340 processes and stores all pertinent transaction 

1 0 information in data storage unit 1342, which allows for immediate access to the 

information by the vendor 1322, the service provider 1320 and any other authorized 
users for verification of data integrity and tracking purposes. The remainder of the 
transaction is similar to embodiments already described, wherein the paying institution 
1352 and the issuing institution 1344 are involved in processing the payment to the 

1 5 service provider once it has been authorized by vendor. Further, the paying and issuing 
institution may be one and the same and can charge its fees to the vendor and service 
provider in the system as it is receiving payments from vendor 1322 and tendering 
payments to service provider 1320. 

As an example of the type of information that could be used in the 

2 0 vendor/service provider scenario, reference is made to the following Tables: 

Table 1 A - Transaction Information 

(Vendor/Service Provider) 



Data Element 


Length 


Type 


DESCRIPTION 


Vendor ID 


10 


N 


Record Vendor ID 


Vendor Office ID 


3 


N 


Record Vendor Office ID 


Quotation # 


15 


AN 


Record ID; also customer PO# 


Ship Date 


8 


N 


Record ID, reporting 


Service Provider 
Terms 


4 


AN 


Payment period 


Consolidated invoice 


1 


N 


l=Yes; 2=No 


Customer Number 


10 


N 


Alternate index, allows Vendor 1220 to 
specify it's customer number 


Customer PO # 


15 


AN 


Alternate index, reporting 
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Data Element 


Length 


Type 


DESCRIPTION 


f~\vA or 44 


1 j 


A XT 

AIN 


Alternate index 


Service Provider 
Order Number 


15 


AN 


Reporting, PO associated with service 
provided 


Service Provider 
Name 


35 


AN 


Name of service provider 



Table 11 - Vendor Profile 



DATA ELEMENT 


WIDT 
H 


TYPE 


DESCRIPTION 


v enuor id 


1 0 

1U 


XT 

IN 


LJIHUUCiy lU-C/llLlllCo d ICgdl CIlLlty liblllg a SlllglC 

quotation system (e.g.engine 1230), assigned 
by the CP 1240. 


/aCCULIIIL ID 




IN 


/\LOULAJUL tt doM^llCU LU V CIIUUI LaLLX) uy IbbUlilg 

processor 1245. 


v enaor in ame 




A /NT 




Vendor Address 1 


32 


A/N 


Headquarters Address 










Vendor City 


28 


A/N 




VDR. State/Province 


3 


A/N 




VDR. Country 


3 


A/N 




VDR.Contact 


32 


A/N 




VDR. Phone 


10 


N 




Open Date 


8 


N 


Supplied by CP 1240 when record is built. 
YYYYMMDD format 


Date of First Activity 


8 


N 


A j j ' 11 1*11 /~1T^ A f\ 1 jC J- 

Automatically supplied by CP 1240 when first 
quote record is received by CP 1240 - 
YYYYMMDD format 


Date of Last Activity 


8 


N 


Automatically updated by CP 1240 every time 
a quote record is processed 


Current Status 


4 


A 


Valid values are OPEN, CLSD, HOLD. 
Automatically updated on effective date if 
effective date was pre-entered or as part of on- 
line transaction when effective date is set to 
today. 


Current Status Date 


8 


N 


Automatically updated by system when 
current status field is updated, YYYYMMDD 
format 


Pending Status 


4 


A 


User will key status, valid values are OPEN, 
CLSD, HOLD 
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DATA ELEMENT 


WIDT 
H 


TYPE 


DESCRIPTION 


Effective Date 


8 


N 


Default to today's date with user ability to 
override to a future date. YYYYMMDD 
format 


Last update date 


8 


N 


Automatically stamped by CP 1240 


Last update time 


4 


N 


Automatically stamped by CP 1240. HHMM 
format 


Last Update User 


8 


A/N 


Automatically pulled from user profile by CP 
1240. 



Table 12 - Vendor/Service Provider Profile 



COLUMN NAME 


DATA 
WIDT 
H 


DATA 
TYPE 


DESCRIPTION 


v enuor xu 


1 0 


"NT 




Service Provider ID 


4 


A/N 




Merchant Number 


10 


N 


Assigned by Paying processor 1254. If 
blank, use default value from service 
provider profile. 


Delivery (POD) 


i 


A 

r\. 


"Y" f nr POD to he recmired "N" for POD 
not required 


Type of POD 


4 


A 


Identifies in what manner the POD is to 
be received. 


Auto close days 


2 


N 


Number of days after which the 
transaction will close and be paid to the 
Service Provider 1222 regardless of 
whether or not POD has been posted. 


Open Date 


8 


N 


Automatically supplied by CP 1240 when 
record is built. YYYYMMDD format 


Date of First 
Activity 


8 


N 


Automatically supplied by CP 1240 when 
first quote record is received by system - 
YYYYMMDD format 


Date of Last 
Activity 


8 


N 


Automatically updated by CP 1240 every 
time a quote record is processed 


Current Status 


4 


A 


Valid values are OPEN, CLSD, HOLD. 
Automatically updated on effective date if 
effective date was pre-entered or as part 
of on-line transaction when effective date 
is set to today. 
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COLUMN NAME 


DATA 
WIDT 
H 


DATA 
TYPE 


DESCRIPTION 


Current Status Date 


8 


N 


Automatically updated by CP 1240 when 
current status field is updated, 
YYYYMMDD format 


Pending Status 


4 


A 


User will key status 


Effective Date 


8 


N 


Default to today's date with user ability to 
override to a future date. YYYYMMDD 
format 


Last update date 


8 


N 


Automatically stamped by CP 1240 


Last update time 


4 


N 


Automatically stamped by CP 1240 
HHMM format 


Last Update User 


8 


A/N 


Automatically pulled from user profile 
lists 



Table 13 - Service Provider Profile 



COLUMN NAME 


DATA 
WIDT 
H 


DATA 
TYPE 


DESCRIPTION 


SP 


4 


A/N 


4 character code that uniquely identifies 
a Service Provider (SP) 1222. 


Merchant Number 


10 


N 


Paying processor 1254 assigns to each 
SP. 


SPp 22 Name 


32 


A/N 


DBA name ofSP HQ 


SP Address 1 


32 


A/N 




SP Address 2 


32 


A/N 




SP City 


28 


A/N 




SP State/Province 


3 


A/N 




SP Country 


3 


A/N 




SP Contact 


32 


A/N 


Name of primary contact at SP HQ 


SP Phone 


10 


N 


Phone number of primary contact at SP 
HQ 



44 



COLUMN NAME 


DATA 
WIDT 
H 


DATA 
TYPE 


DESCRIPTION 


Open Date 


8 


N 


Automatically supplied by CP 1240 
when record is built. YYYYMMDD 
format 


Date of First 
Activity 


8 


N 


Automatically supplied by CP 1240 
when first quote record is received by 
system on this SP 1222 - 
YYYYMMDD format 


Date of Last Activity 


8 


N 


Automatically updated by system every 
time a quote record is processed for this 
SP 1222 


Current Status 


4 


A 


Valid values are OPEN, CLSD, HOLD. 
Automatically updated on effective date 
if effective date was pre-entered or as 
part of on-line transaction when 
effective date is set to today. 


Current Status Date 


8 


N 


Automatically updated by CP 1240 
when current status field is updated, 
YYYYMMDD format 


Pending Status 


4 


A 


User will key status 


Effective Date 


8 


N 


Default to today's date with user ability 
to override to a future date. 
YYYYMMDD format 


Last undate date 


8 


N 


Automatically stamped by CP 1240 


Last update time 


4 


N 


Automatically stamped by CP 1240 
HHMM format 


Last Update User 


8 


A/N 


Automatically pulled from user profile 
lists by CP 1240 



Table 14 - Vendor/Service Provider Access Terminal Profile 



COLUMN NAME 


WIDT 
H 


TYPE 


DESCRIPTION 


Vendor ID 


10 


N 


Uniquely identifies a legal entity using a 
single quotation system (e.g engine 1230) 


SPID 


3 


N 


Uniquely identifies a particular physical 
location with a Service Provider ID. 


Account ID 


16 


N 


Issuing Processor 1254 assigns. Defaults 
from SP profile, can be overridden by 
vendor 
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COLUMN NAME 


WIDT 
H 


TYPE 


DESCRIPTION 


CD XTa-m<a 

or i\iame 


X) 


A/XT 


lvJD/Ti. iiaiiit/ VJi OJr vjiign idling \^u.\jlv 




x> 


A/NT 

/VIM 


OUCCL aUlUCob Ul ul VJl lgllidLlllg L[U.VJLt< 


or /vQuress z 


X) 


A/NT 




SP City 


28 


A/N 




ISr Mate/rrovince 


J 


A /XT 

A/ IN 




SP Country 


3 


A/N 




SP Contact 


32 


A /XT 
A/N 




SP Phone 


10 


N 


To be used for reporting against completion 
transaction 


Open Date 


8 


X T 

N 


Automatically supplied by CP 1240 when 
record is built. YYYYMMDD format 


Date of First 
Activity 


8 


XT 

N 


Automatically supplied by CP 1240 when 
first quote record is received by system - 
YYYYMMDD format 


Date of Last 
Activity 


8 


N 


Automatically updated by CP 1240 every 
time a quote record is processed 


Current Status 


4 


A 


Automatically updated by CP 1240 on the 
effective date if effective date was pre- 
entered or as part of the on-line transaction 
if the effective date is changed to today. 
Valid values are UrLJN, LLoD, fiULD 


Current Status Date 


8 


N 


Automatically updated by CP 1240 when 
current status field is updated, 
YYYYMMDD iormat 


Pending Status 


4 


A 


User will key status 


Effective Date 


8 


N 


Default to today's date with user ability to 
overnde to a ruture date. Y r y y ivlmjjjj 
format 


Last update date 


8 


N 


Automatically stamped by CP 1240 


Last update time 


4 


N 


Automatically stamped by CP 1240 
HHMM format 


Last Update User 


8 


A/N 


Automatically pulled from user profile lists 



Table 15 - Service Quotation Data Elements 



Data Element 


Length 


Type 


Source 


Purpose 


Vendor ID 


10 


N 


CP 1240 


Record ID 


SPID 


3 


N 


CP 1240 


Record ID 


Account ID 


16 


N 


CP 1240 


Record ID; reporting 
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Data Element 


Length 




Source 


Purpose 


Quotation # 


15 


AN 


SP 


Record ID 


Service Date 


8 


N 


SP 


Record ID, reporting 


SPAC 


4 


A 


SP 


Alternate index, identifies 
Service Provider 


Merchant # 


10 


N 


CP 40 


Alternate index, for CP 1240 
usage 


Vendor # 


10 


N 


SP 


Alternate index, allows SP to 
specify its vendor number for 
a given vendor 


Customer Number 


10 


N 


Vendor/ 
SP 


Alternate index, allows 
Vendor or SP to specify it s 
customer number 


Customer PO # 


15 


AN 


SP 


Alternate index ? reporting 


(Quote #) 










SP Order # 


15 


AN 


SP 


Alternative Index 


Vendor Order 


15 


AN 


SP 


Reporting, alternate locator 


Number 










Vendor Name 


35 


AN 


SP 


Reporting 


Vendor Contact 


20 


A 


SP 


Claims 


Person 










Vendor Phone # 


15 


A XT 

AN 


SP 


Claims 


Origin Designator 


iU 




CD 


Reporting 


City 


20 


AN 


SP 


Reporting 


State 


2 


A 


SP 


Reporting 


ZIP Code 


9 


N 


SP 


Reporting 


Division Code 


2 


AN 


SP 


Reporting 



Table 16 - Service Quotation Line Item Detail Data Elements 



Data Element 


Length 


Typ 

e 


Source 


Purpose 


Vendor ID 


16 


N 


CP 1240 


Record ID 


Quotation/PO # 


15 


AN 


SP 


Record ID 


Service Date 


8 


N 


SP 


Record ID 


Service Description 


28 


AN 


SP 


reporting, claims 


Serrvice Program ID 


8 


AN 


SP 


reporting, claims 
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The above-described system can be used by authorized representatives (or 
agents) to help customers subscribe to other types of services for a fee. Travel agents are 
already commission-based when they assist customers in making reservations for 
lodging, air and land transportation; however, they can now be tied to this system for 
5 faster processing of payments back to them in return for a fee that can be charged by the 
banking institution for this service. 

The system can also be used in the area of providing wireless communications 
services (or entertainment services such as satellite programming or satellite 
communications) to third party customers , via authorized or empowered 

1 0 representatives, to verify that customers have the correct equipment and software to 
receive the service from the communications vendor. The representative is involved in 
preliminary issues of credit checks and programming selection and is the normal contact 
for the customer if any service issues arise. The representative is paid a fee for the 
initial set up and ongoing support of the customer using the transaction validation 

1 5 system described to ensure that the work was properly done and that payment is issued 
to the authorized representative by an authorized user of the system. This system is also 
applicable in the area of video conferencing services, where a third party customer is 
interested in working with the communication services vendor through a 
communications consultant. The consultant helps to set up the equipment and software 

2 0 required to connect to the video conferencing network and is there to service the 

customer's needs on an ongoing basis. The consultant provides all of the services for a 
fee to be paid by the communications service vendor. 

Software or information technology (IT) developers also benefit from this 
system when using IT consultants that work closely with third party customers, 

2 5 specifically when such customers need help in upgrading and maintaining their systems. 
The IT consultants are paid using the transaction validation system described for 
services rendered. Companies selling products through online (Internet) agents such as 
Buy.com, eBay.com or eToys.com or via a normal telephone (such as florists, catalog 
purchases, QVC, Home Shopping Network, etc..) also benefit from this system. 
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The role of a "vendor" is becoming blurred as more companies start to shift their 
manufacturing of products to companies that specialize in the manufacture of that type 
of product in response to the customer's demand for lower cost, shorter lead times and 
better technology. This is especially true in the area of computers and consumer 
5 electronics. OEM companies like IBM and HP, in the computer area, and Ericsson and 
Qualcomm, in the mobile communications area, have shifted much of their 
manufacturing to contract manufacturers such as Solectron and Flextronics. Contract 
manufacturers have the capability of taking the engineered designs of these customers 
and manufacturing them at the lowest possible cost due to their purchasing strength and 

1 0 logistic capabilities. They in turn will ship the completed product to the end customer 
(e.g. Circuit City, Best Buy, and etc..) on behalf of the OEM and invoice that customer 
if the OEM chooses that method. Here the contract manufacturer has control of the 
carrier that will be shipping the product to the OEM's customer. In the eyes of the 
customer the vendor is still the OEM that is the party receiving the P.O. and whom they 

15 are holding responsible if the product has a problem or is not shipped on time. The 
emerging vendor/sub vendor relationship, including the service provider (providing 
transportation services in this case) who is involved in this type of transaction, requires 
the banking institution to ultimately pay the service provider and subvendor when it is 
authorized by the vendor to do so. This is another opportunity for the banking 

2 0 institution to expedite auditing and financial negotiations due to the presence of the 
subvendor in this equation. 

Referring now to the example process depicted in connection with FIG. 14, 
vendor/OEM 1420 receives a purchase order through vendor processor 1424 A from a 
customer for product/equipment with a requested shipping date. Processor 1424 A 

2 5 initiates a transaction by acting in conjunction with subvendor processor 1424B and 

quotation generating engine 1430 to generate a quote for the equipment and shipping 
date for the customer. Subvendor processor 1424B sends the quotation to vendor 
processor 1424 A and to a data processing device 1434 of the subvendor access terminal 
1432. Vendor can now add their markup before advising customer of equipment ship 

3 0 date but now knows what it owes the subvendor if the entire transaction occurs as 
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planned. The data processing device 1434 generates the transaction information and 
sends the transaction information to the central processor 1440, which in turn identifies 
and centrally tracks the transaction information. A service provider device 1446 
receives proof of delivery information and sends this information to the central 
5 processor 1440. Central processor 1440 processes and stores all pertinent information 
in a data storage unit 1442 and allows immediate access to their information by the 
vendor, subvendor and the service provider. When vendor processor 1424 A receives 
confirmation or proof of delivery then it, or its authorized agent/user, will authorize 
payment to subvendor. This is also a signal to subvendor that the subvendor controlled 

1 0 service provider 1422 can now be paid. Service provider's 1422 notice to central 
processor 1440 that delivery is confirmed reaches both vendor and subvendor 
simultaneously through central processor 1440 to ensure a closed loop system. The 
issuing processor 1445, of the issuing institution 1444, maintains a credit account for 
both the vendor 1420 and subvendor 1421 and debits the vendor's account for the cost 

1 5 of the entire project (which was calculated with a different algorithm initially to avoid 
disclosing cost information to the end customer) when payment to subvendor is 
authorized by vendor. Subvendor' s account is debited by issuing processor 1445 for 
cost of service provider's 1422 service when authorized by subvendor. The remaining 
part of the auditing and payment system is substantially similar to embodiments 

2 0 described above. 

Referring briefly to Tables 1-7, the content of these tables for the 
subvendor is similar to that of the shipper/carrier scenario described earlier since the 
service provider is acting like a manufacturer of goods that needs to ship product to a 
customer via a carrier. Additional profiles similar to Table IB (Transaction Information 

2 5 - Vendor/Subvendor/Service Provider), Table 8 (Vendor Profile) and Table 9 

(vendor/subvendor profile) would be developed for a particular transaction. The 
subvendor can provide part of the service package that the vendor has contracted him to 
do and have the package delivered to the end customer through another party that will 
act as a service provider. For instance, IBM contracts with a subvendor to install a 

3 0 software update for a global IBM customer with a presence in Costa Rica. The 



50 



subvendor in turn contracts with a local Costa Rican software consultant (service 
provider) to perform the actual software update at the customer site. Once the tables 
have been established and put into the system (and the authorized users identified) the 
auditing and payment operations can be performed substantially the same as described 
5 in earlier embodiments. 



Table IB - Transaction Information 

(Vendor/Subvendor/Service Provider) 

10 



Data Element 


Length 


Type 


DESCRIPTION 


Vendor ID 


10 


N 


Record Vendor ID 


Vendor Office ID 


3 


N 


Record Vendor Office ID 


Quotation # 


15 


AN 


Record ID; also customer PO# 


Ship Date 


8 


N 


Record ID, reporting 


Subvendor Terms 


4 


AN 


Payment period 


Consolidated invoice 


1 


N 


l=Yes; 2=No 


Customer Number 


10 


N 


Alternate index, allows Vendorl420 to 
specify it's customer number for a 
given receiver 


Customer PO # 


15 


AN 


Alternate index, reporting 


Order # 


15 


AN 


Alternate index 


Subvendor Order 
Number 


15 


AN 


Reporting, PO associated with shipment 


Service Provider 
Name 


35 


AN 


Name of service provider or shipping 
company 



Table 8 - Vendor Profile 



DATA ELEMENT 


WIDT 
H 


TYPE 


DESCRIPTION 


Vendor ID 


10 


N 


Uniquely identifies a legal entity using a single 
quotation system (e.g. engine 1430), assigned 
by the CP 1440. 


Account ID 


16 


N 


Account # assigned to Vendor 1420 by issuing 
processor 1445. 


Vendor Name 


32 


A/N 




Vendor Address 1 


32 


A/N 


Headquarters Address 
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DATA ELEMENT 


WIDT 
H 


TYPE 


DESCRIPTION 














A/NT 




VDR. State/Province 


3 


A/N 






D 


A/NT 
IN 




VDR.Contact 


32 


A/N 




VDR. Phone 


10 


N 




Open Date 


Q 
O 


XT 

JN 


Supplied by CP 1440 when record is built. 
YYYYMMDD format 


Date of First Activity 


o 
0 


XT 

N 


Automatically supplied by CP 1440 when first 
quote record is received by CP 1440 - 
YYYYMMDD format 


Date of Last Activity 


8 


N 


Automatically updated by CP 1440 every time 
a quote record is processed 


Current Status 


4 


A 


Valid values are OPEN, CLSD, HOLD. 
Automatically updated on effective date if 
effective date was pre-entered or as part of on- 
line transaction when effective date is set to 
today. 


Current Status Date 


O 

0 


XT 

N 


Automatically updated by system when 
current status field is updated, YYYYMMDD 
format 


Pending Status 


4 


A 


User will key status, valid values are OPEN, 
LLSD, HOLD 


Effective Date 


8 


N 


Default to today's date with user ability to 
override to a iuture date. Y Y Y YMMDL) 
format 


Last update date 


8 


N 


Automatically stamped by CP 1440 


Last update time 


4 


N 


Automatically stamped by CP 1440. HHMM 
format 


Last Update User 


8 


A/N 


Automatically pulled from user profile by CP 
1440. 



Table 9 - Vendor/Subvendor Profile 



COLUMN NAME 


DATA 
WIDT 
H 


DATA 
TYPE 


DESCRIPTION 


Vendor ID 


10 


N 




Subvendor ID 


4 


A/N 
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COLUMN NAME 


DATA 
WIDT 
H 


DATA 
TYPE 


DESCRIPTION 


Merchant Number 


10 




Assigned by Paying processor 1454. If 
blank, use default value from subvendor 
profile. 


Proof of Delivery 
(POD) 


1 


A 


"Y" for POD to be required, "N" for POD 
not required 


Type of POD 


4 


A 


Identifies in what manner the POD is to 
be received. 


Auto close days 


2 


N 


Number of days after which the 

, J * '111 11 " 1 > j 1 

transaction will close and be paid to the 
Subvendor 1422 regardless of whether or 
not POD has been posted. 


Open Date 


8 


N 


A j j* 1 1 I'll jf^i^T**. <4 A A S~\ 1 

Automatically supplied by CP 1440 when 
record is built. YYYYMMDD format 


Date of First 
Activity 


8 


N 


Aj j" 1 1 I'll jf~*iT\ -1 A A i 

Automatically supplied by CP 1440 when 
first quote record is received by system - 
YYYYMMDD format 


Date of Last 
Activity 


8 


N 


Automatically updated by CP 1440 every 
time a quote record is processed 


Current Status 


4 


A 


Valid values are OPEN, CLSD, HOLD. 
Automatically updated on effective date if 
effective date was pre-entered or as part 
of on-line transaction when effective date 
is set to today. 


Current Status Date 


8 


N 


Automatically updated by CP 1440 when 
current status field is updated, 
YYYYMMDD format 


Pending Status 


4 


A 


T T * 1 1 1 j j 

User will key status 


Effective Date 


8 


N 


Default to today's date with user ability to 
overnde to a future date. YYYYMMDD 
format 


Last update date 


8 


N 


Automatically stamped by CP 1440 


Last update time 


4 


N 


Automatically stamped by CP 1440 
HHMM format 


Last Update User 


8 


AM 


Automatically pulled from user profile 
lists 



In another embodiment it is envisioned that the different users of the 
system may be located remotely from the transaction validation system and are 



53 



accessing the system and its database through system processors or computer-like 
mechanism. For instance, the vendor, subvendor or service provider may be in a foreign 
country but accessing the transaction system and the central processor arrangement in 
the U.S. via a computer or a network that connects that user with the transaction system 
that may be in the U.S. The transaction system and its users need not be co-located. 
Specifically in Figures 12 and 13, vendor processor 1224 or service provider processors 
may be tapped into remotely, but to the system these users may appear to be local and 
using their processors locally to access and use the system. 

Accordingly, the present invention provides, among other aspects, a computer 
processing system for a shipment transaction involving a shipper and a carrier. Further, 
the present invention provides a computer processing system and method for auditing a 
transaction between a vendor and a service provider in the area of services. Finally, the 
present invention provides a computer processing system and method for auditing a 
transaction between a vendor, subvendor and a service provider. Other aspects and 
embodiments of the present invention will be apparent to those skilled in the art for 
consideration of the specification and practice of the invention disclosed herein. It is 
intended that the specification and illustrated embodiments be considered as exemplary 
only, with a true scope and spirit of the invention being indicated by the following 
claims. 
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1 



What is claimed is: 



1 1 . For transaction processing involving transaction information related to services 

2 provided by one of a plurality of vendors and processed by one of a plurality of service 

3 providers, a transaction validation system for auditing comprising: a central processor 

4 arrangement programmed and configured to maintain data relating to an authorized 

5 profile list criterion that includes information about authorized users empowered to 

6 authorize payment by the vendor, and programmed and configured to process the 

7 transaction information by determining whether the transaction information satisfies the 

8 authorized profile list criterion, and using the authorized profile list criterion to generate 

9 information for auditing a transaction between said one of a plurality of vendors and 
1 0 said one of a plurality of service providers 

12. A transaction validation system for auditing according to claim 1, wherein said 

2 system further includes a means for generating a quotation coupled to said central 

3 processor arrangement. 

1 3. For transaction processing involving transaction information related to services 

2 provided by a vendor, said transaction information initially being generated by one of a 

3 plurality of service providers prior to processing by said vendor, a transaction validation 

4 system for auditing comprising: a central processor arrangement programmed and 

5 configured to maintain data relating to an authorized profile list criterion that includes 

6 information about authorized users empowered to authorize payment by the vendor to 

7 the service provider, and programmed and configured to process the transaction 

8 information by determining whether the transaction information satisfies the authorized 

9 profile list criterion, and using the authorized profile list criterion to generate 

1 0 information for auditing a transaction between said vendor and said one of a plurality of 

1 1 service providers. 
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4. A transaction validation system for auditing according to claim 3, wherein said 
system further includes a means for generating a quotation coupled to said central 
processor arrangement. 



1 5 . A transaction processing involving transaction information related to services 

2 provided by a vendor and a plurality of subvendors and processed by one of a plurality 

3 of subvendor controlled service providers, a transaction validation system for auditing 

4 comprising: a central processor arrangement programmed and configured to maintain 

5 data relating to an authorized profile list criterion that includes information about 

6 authorized users empowered to authorize payment by the vendor and subvendors, and 

7 programmed and configured to process the transaction information by determining 

8 whether the transaction information satisfies the authorized profile list criterion, and 

9 using the authorized profile list criterion to generate information for auditing a 

1 0 transaction between said vendor and both of said plurality of subvendors and said 

1 1 plurality of subvendor controlled service providers. 

1 6. A transaction validation system according to claim 5, wherein said system further 

2 includes a means for processing transactions for each of said vendor and said 

3 subvendor, said processing transaction means coupled to said central processor 

4 arrangement. 

17. A transaction validation system according to claim 2, wherein said system 

2 further includes a means for processing transactions for each of said vendor and said 

3 service provider, said processing transaction means coupled to said central processor 

4 arrangement. 

18. A transaction validation system according to claim 8, wherein said processing 
2 transaction means is accessible remotely. 
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19. A transaction processing system involving transaction information related to 

2 services provided from one of a plurality of vendors and processed by one of a plurality 

3 of service providers, a method for validating a service transaction for auditing 

4 comprising: 

5 generating transaction information prior to processing by vendor; 

6 providing an authorized profile list criterion that includes information about 

7 authorized users empowered to authorize payment by the vendor; 

8 using a computer arrangement, maintaining data relating to the authorized 

9 profile list criterion and processing the transaction information by determining whether 

1 0 the transaction information satisfies the authorized profile list criterion, and by using the 

1 1 authorized profile list criterion to generate information for auditing a transaction 

12 between said one of a plurality of vendors and said one of a plurality of service 

13 providers. 

1 10. A method for validating a service transaction, according to claim 9, further 

2 including sending service-related information from an external device and generating a 

3 set of transaction information therefrom. 

1 11. A method for validating a service transaction, according to claim 10, further 

2 including informing the computer arrangement of provision of the service by the service 

3 providers, and using the computer arrangement to audit the service transaction and 

4 payment thereof in response to the transaction information and the authorized profile list 

5 criterion. 

1 12. The method according to claim 9, further including communicating service 

2 related information to said computer arrangement from remote location. 

1 13. For transaction processing involving transaction information related to services 

2 provided from a vendor and one of a plurality of subvendors and processed by one of a 
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3 plurality of subvendor controlled service providers, a method for validating a service 

4 transaction for auditing comprising: 

5 generating transaction information prior to processing by subvendor; 

6 providing an authorized profile list criterion that includes information about 

7 authorized users empowered to authorize payment by the vendor; and 

8 using a computer arrangement, maintaining data relating to the authorized 

9 profile list criterion and processing the transaction information by determining whether 

1 0 the transaction information satisfies the authorized profile list criterion, and by using the 

1 1 authorized profile list criterion to generate information for auditing a transaction 

1 2 between said one of a plurality of vendors and said one of a plurality of service 

1 3 providers. 



1 14. A system for billing a vendor and subvendor, and paying a service provider and 

2 a subvendor for a completed service-related transaction, comprising: 

3 means for receiving a set of transaction information including the cost of service 

4 from a central processor arrangement; and 

5 means for processing a credit account for the vendor, for verifying that the 

6 vendor has sufficient credit to fund the cost of service, for indicating when the account 

7 for the vendor should be debited, and for indicating when payment to the service 

8 provider and subvendor should be tendered, and for notifying a financial institution the 

9 cost of service. 

1 15. A method for billing a vendor and subvendor, and paying a service provider and 

2 a subvendor for a completed service-related transaction, comprising: 

3 receiving a set of transaction information including the cost of service from a 

4 central processor arrangement; and 

5 using a computer arrangement for processing a credit account for the vendor, for 

6 verifying that the vendor has sufficient credit to fund the cost of service, for indicating 

7 when the account for the vendor should be debited, for indicating when payment to the 
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8 service provider and subvendor should be tendered, and for notifying a financial 

9 institution of the cost of the service. 
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Abstract 

A computer processing system for auditing transaction information 
between vendors and service providers servicing a third party's needs. The system also 
5 includes those transactions involving shippers and carriers. The system is particularly 
suited to efficiently and automatically audit and effect payment of a transaction and to 
efficiently provide access to relevant transaction and subscription information. 
According to one example embodiment, the system includes a processor arrangement 
that helps vendors validate transactions between service providers and third party 

1 0 customers. In some cases the system is able to monitor transactions initiated by the 
service provider, for the benefit of the customer, committing the vendor to certain 
actions not readily known by vendor. However, this is acceptable if the service provider 
uses a service quotation generating system, provided by the vendor, that has pre- 
determined parameters that vendor is willing to be committed to in order to immediately 

1 5 secure the new subscriber. 
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